Future plans

Well, things are coming along at the moment here at Heretik Forge.

The PPG design has had it’s final field test, and somewhat surprised everyone (and proven I can’t shoot for toffee).
The basic sensors have again been field tested and production is about to ramp up for the game next year.

So thoughts have quite naturally started working on what next?

Currently I’m thinking along the lines of:

• A Standardized circuit including an ammunition indicator light and reload switch – The PPG circuits were only ever a temporary design for a very specific body so a number of compromises were made. So a “Standard” circuit design with more powerful output and running off of 7.2 or 9V (6 rechargable Ni-cads or 6 alkaline batteries) is in the prototype stage – there will need to be 2 versions, as currently if you connect the 7.2V circuit to a 9V power supply everything will work, but it would blow the emitter – Current plan is to differentiate the designs via the battery connector – Tamiya connector for 7.2V and standard battery snaps for the 9v (pics needed)

• Verostrip/Veroboard layouts for everything – This is to go alongside the etched layouts, so that if someone wants to make a circuit they can go with whichever method they are most familiar and/or comfortable with.

• Pre-focused LED/Lens assembly – 16mm, 20mm 30mm and 40mm lens/barrel assemblies this along with pre-programmed chips I can see making it a little easier – an etsy store might be the best route to go for these – This could then be expanded to include pro etched boards/components in a kit package, adaptors for nerf bosied and all sorts of things.

• Variant circuits that have different output signals for sound )Simple high/low trigger) as I know there are some out there that are interested in using repurposed Toy sound boards.

• Variant sound modules – I know there are audio modules that are basically identical to the one sI ‘m currently using but use flash memory rather than microSDcard which would given another option for audio on circuits.

• Data signals for more advanced functions/capabilities

More advanced circuits/signals are tricky. I know if I ask I’ll get the DoT* information for the Data-over-Tag system.

But at the same time, I haven’t asked for it, and I won’t ask for it either.

I know the creator of DoT is very careful with who he shares the information with for reasons of his own:
[Quote]
I did refuse to give someone any info, and that’s because I didn’t trust them, still don’t and never will. Requests were treated on a case by case basis.
[Endquote]

As the quote from the comments on here shows, one of which  is that he does not want some people to have access to the information. Fair enough, he developed it so it's up to him what he does with it. 😊

I on the other hand plan to make everything open source/creative commons and available, which would mean making the DoT code and protocols open source – but as they are not mine, that’s not a decision that’s up to me.

So, I’m left with developing a data signal protocol myself.

Which also means making enough kit to potentially cover everyone on a game, which is a little daunting, but hey... I'm up for a challenge :)

I’ve some ideas that are still theoretical at the moment as I’ve been working on the higher priority stuff for the game, but as the signal I’ve in mind is based on a modified ethernet type signal I think it’s just a case of sitting down and doing the grunt work to get it going.

The signal itself I’m seeing as a 60ms WoW hit signal** followed by 3-4 iterations of the serial data.

In the sensor, when it gets a WoW signal it reads that in for 50-60ms, then reads in any further data into memory for x period of time (so it times out if it’s just a “standard” WoW or DoT signal)– Provided it is a Standard WoW signal, it then goes through the information read into memory looking for a specific start character, acts on the data after the start character to an end character.

The 60ms length of the WoW pulse, and the 3-4 iterations is to give a little leeway to the signal, so it does not need to be as extremely rigidly controlled - For example a system that uses a pulse width modulated signal at frequency x needs to be quite carefully controlled, timed and constructed by the code in the microprocessor.

From my research, I think the way I’m thinking of the signal would enable the output code on the processor and the input code on the processor to be built from existing libraries (Pulse width signal generation and serial data transmission), making it a little simpler to migrate across different hardware platforms (Picaxe, pic, Arduino raspberry pi etc etc), which is in line with one of the basic ideas/principles for my Heretik forge stuff.

I’m going to be busy for quite some time

---

* DoT - Data over Tag, a data transmission system used primarily by the UKLTA

** WoW Hit signal is a signal consisting of a 57.6kHz signal and 1800hz signal modulated together