New sounds....

So. I’ve recently worked out how to get an alternate audio module working for the various circuits.

But Why? I hear you asking(1)

Simples.

Cost.

The previous circuits used the DFplayer audio module. Which work out at a round a little over £1 each, depending on the exchange rate. The new modules, cost a little bit more, but not by much.

HOWEVER. The new modules have onboard Flash Memory whereas the DFPlayer modules use microSD cards. Which increase the cost substantially. It’s fine when your making just one or two things, but the last big project for Babylon 5 earlier this year, needed around 50 audio modules. That’s a LOT of extra money to find.

The only possible concern is the capacity of the flash memory – I’ve not fully checked out how much it can hold yet. They are also slightly larger, and a different pin layout which is more of an issue when working with Veroboard, as when I get the professionally made boards designed and sorted they are a lot easier to fit on. Even if it’s looking like I’ll have to do the design work and layout for the module myself for using in EAGLE PCB software (straight forward enough as I can start of with the DF player and edit it)

So, along with the change to Pic chips, the new audio modules with drastically lower the basic cost of emitter or sensor circuits by a good £3-£6 each.

I’ve not done the full working out yet, but I’m hoping, when everything is finally ready and released open source, to also be able to offer pre-programmed Pic chips, or Pre-flashed sound modules as well as professionally etched boards, and fully assembled boards for as close to £10-£15 each as possible for the emitters and whatever it works out at for the sensors.

Essentially, as well as the plans and both hex files and code to build the things to be able to offer kits, or pre-built circuits that just need the various buttons and speakers attaching (I’m thinking of including the Emitters, as the ones I use, weirdly have the legs setup so that positive/negative are indicated the opposite way round to pretty much every other LED I’ve seen… Or at least, pre-wired emitters with the traditional red/black for positive/negative.

But that’s for the future. In the meantime, the only separate thing I need to sort out for the pic circuits, before smooshing it all together in the code is counting the pulses to check the frequency….

And I’d have had that done by now if I wasn’t waiting for new IR receivers to arrive(4)

1: I do…. I can hear EVERYTHING(2)

2: Or I may just be overtired and having audio-hallucinations.. Hey-ho

3: Normally, positive is on the longer leg, negative on the shorter… Not on these puppies.. Oh no….

4: So, it turns out, that if you accidentally wire the +ve and -ve on an IR receiver backwards on your development breadboard and blow it… It’s a good idea to correct the wiring before going “Oops” and just replacing the blown one with the last one you’ve got in the house…..

Another nail in the Picaxe sensor's coffin...

More work done on migrating the circuits to Pic this weekend in between watching the Rugby World cup and Ghostbusters 35th anniversary…

 

I was originally planning on having pic and picaxe development running concurrently and releasing both open source as Picaxe use Basic.

However a snag has been found.

 

Picaxe has two commands for dealing with reading serial data SERIN and HSERIN. SERIN enables serial communication on pretty much any pin. HSERIN uses the hardware of the underlying pic. There is a difference between the two – Over the weekend, I was working on constructing the signal – having got the baud rates set and the timings sorted down to the millisecond (Well… nanosecond pretty much) The Legacy side of the hit works fine. The problem is the SEROUT/SERIN command for output/input – the actual length of time it takes to send the serial data is longer than the equivalent from the Pic, or from HSEROUT.

This in itself isn’t too much of a problem, apart from when it comes to reading the signal. SEROUT creates a much longer serial code than the hardware equivalent. Meaning that a sensor as they currently stand, cannot read the serial data part of the signal if it has been generated by a PIC. I think this can be mitigated by changing from SEROUT/SERIN to HSEROUT/HSERIN to use the underlying pic hardware.

 

But, given the other limitations of the Picaxe based sensors, I just cannot be bothered to faff around with something that I already know won’t be able to handle everything I want it to.

Changing the Picaxe based sensors to Pic is straight forward enough – I’ve got to reprogram the chips back to their underlying pic chip (Programming a Picaxe as the underlying Pic removes the Picaxe bootstrap/compiler from the chip) swap two pins around on the hardware – which should be basically move 1 wire and 1 resistor – all it’ll cost is 1 resistor unless I get lucky with the leg length, but that’s not really an issue to worry about.

 

It is essentially another nail in the coffin of the advanced Picxe based sensors 😊

 

The whole project would be even easier if I wasn’t also trying to make sure that Legacy WoW kit worked with it as well, as in that case I’d change the signal to a relatively straight forward serial data stream and get rid of the 1800hz 50ms hit frequency. BUT I am, so I’m not 😊 )

PIC'ing the chips :)

Well, PIC migration has started in earnest now…

 

Following a few setbacks…..

Bit of a pain when the programmer you have is no longer supported.

More of a pain when the new programmer doesn’t have one of the useful features of the old one – I’ve moved to Pickit3 programmer from Pickit2. The only drawback I’m finding is that the Pickit3 programmer does not seem to have the capability to act as a serial communication interface – by which I mean with the Pickit2 (and picaxe cables) you could use them to communicate with a terminal program on the PC so you could see the results of serial output, or simulate a serial input – which was rather useful.. actually.. fairly critical in being able to get the serial communication part of the Arcturus signal working. It’s also useful in seeing what is being sent to the audio modules to ensure the correct commands are being sent.

I can’t do that with the Pickit3.

Bugger.

I CAN get a usb-serial interface doohickey that will let me do that and that should be arriving tomorrow all being well. Even though it’ll mean an extra thing cluttering the workbench – But that’s a definite 1^st world problem 😊

Once that arrive I’ll be able to figure out what I’m doing wrong with the serial signal at the moment and get it sorted. Then after that all I need to do is internally modulate the signal and the hardware side of the migration is sorted – It’s just a case of writing the code to slot it all into.

YAY 😊

 

HOWEVER…. Yeah.. There is always a however ain’t there 😊

 

What I CAN’T do (at least for the emitter circuits) is a pin for pin replacement of Picaxe for Pic.

Why? Well, it seems that for some of the functions of the processor, rather than using the hardware modules on the underlying Pic, the Picaxe uses software equivalents.

For example: Interrupts

Interrupts are useful little things that enable you to tell the processor that something has happened and to well.. interrupt what it’s doing and deal with it. This is useful for things like detecting button presses or incoming signals (Y’know… nothing much.. just something that makes up most of what I want 😊 ).

Now, the Picaxe 14M2 chip I use has external interrupts (for button presses) available on pins 5,6 & 7. The underlying Pic chip (16F1825) has external interrupts on PortA – that is, pins 2,3,4,11,12 & 13 – While this is handy as I need more interrupts, it’s a pita – not a HUGE pita as it’s a  minor change going forwards. The biggest problem is the sensors – Luckily the interrupts on the pic used in the sensors are fine – the possible issue with those is the signal input/reading may need to change pin. Handily though if that’s the case, the sensors boards are modular so it’s not too much to change them out (at the cost of some Veroboard, couple resistors, IC chip socket and some soldering).

It’s a similar case with the serial comms, the Picaxe has it on a number of the pins, but the Pic there are a choice of 2 pins – and one of those is the one that will output the modulated signal so that narrows it down even more. The Picaxe has a dedicated command to output/input via the same pin as the Pic.

 

Still. Things are coming along steadily, and given that the Picaxe chips were initially intended as a teaching/learning tool, they have certainly done that, as if I’d have gone straight into the Pic development, I wouldn’t have known where to even begin so in that respect they have been perfect.

 

But it’s time to move on.

Mind you, it also helps that the Pic chips are slightly less than half the price of the Picaxe based on them 😊

Keeping it Simple

One think that’s been bobbing about at the back of my mind is making the code easy to customise – In particular the various components of the data signal. At present they are pretty much hard coded into the code for development, but going forwards I’m going to move away from that idea, so that if someone did not want to use any of the “standard” setups, they can amend the signal to cover whatever is needed.

The easiest way to do this would be to include an additional header/include file that only contains the definitions of what the magazine size is and what each byte will be. When compiled these would then be included in the code, without having to edit the code at all.

The actual values would be in the documentations, though it would also not be too bad to ad a comment section to the file with the same information, or at least a summary of the information as well.

Pretty much the format below:

#define magazine_size 30

#define signal_byte_1 01

#define signal_byte_2 00

#define signal_byte_3 00

#define signal_byte_4 00

#define signal_byte_5 00

//this would be a standard 1 hit damage shot with a magazine size of 30

With comments in the define file giving the value options. That way the only changes needed are in the HFA_Setup.INC or HFA_setup.H files to change the pewpew behaviour

If do implement a 2^nd mode switch (I.e. Kill/stun) also include

#define signal2_byte_1 02

#define signal2_byte_2 01

#define signal2_byte_3 00

#define signal2_byte_4 00

#define signal2_byte_5 00

This would be a stun shot with 5 minute duration.

So the full include/header file for a 30 shot magazine, 1 point no special damage alternate fire mode of 5 minute stun would be:

/*************************************************************

HFA_Setup.H – set the customisable data for the Heretik Forge/Arcturus

                                IR Emitter circuit. This enables anyone who is willing to

                                Customise the output for the circuits to go alongside

                                The “standard” setups that are ready and in the case

                                Of the C/Pic files already compiled into the Hex file

                                Ready to burn onto the chip

*************************************************************

Created: 19/9/19 by Ady: heretikforge@gmail.com

*************************************************************/

#define magazine_size 30

#define signal_byte_1 01

#define signal_byte_2 00

#define signal_byte_3 00

#define signal_byte_4 00

#define signal_byte_5 00

#define signal2_byte_1 02

#define signal2_byte_2 01

#define signal2_byte_3 00

#define signal2_byte_4 00

#define signal2_byte_5 00

Code & Legibility...

So.. As part of working on the Pic chips, I’ve been working on code based on the info in the datasheet* ready for when the new programmer arrives.

Just a simple thing to get the basics for generating the signal for the Arcturus emitters.

Actually, just setting it up to generate a single pulse width modulated signal, and calculations aside,
it’s actually fairly straightforward to do.

I’ve also been doing the same thing with the Microchip Code Configurator** to compare the code.  And I’ll admit, that based on the experience with the code configurator that it’s easy to setup the various bits & bobs of the chip with it.


HOWEVER it does not generate particularly easy to read code – For example, setting up a Pulse width modulated signal –
Takes a couple dozen lines of code if you include  the initial chip setup commands. Easy enough to read and comment.
The code configurator generated 12 FILES with a little bit of code in each – 6 source files and 6 header files. An absolute nightmare to read and make sense of as it’s jumping around through files in what feels like a totally unnecessary manner.

 

For me, that’s a HUGE negative as pretty much the first thing that was hammered in when I started coding way back was to make the code as understandable and easy to read as possible. And There have been many times I’ve been into code that is just horrible. Bad comments or no comments even less documentation and generally just a nightmare to work with.

 

So yeah…. That’s a thing that happened. And given that I plan to release it open source, legibility and ease of understanding is far  more important that saving a little time by using a wizard.

 

 

* I swear for a microcontroller datasheet is a misnomer. 500 pages is a tad more than a sheet if you ask me…

** Microchip code configurator or MCC is essentially a wizard to generate ready to use code tailored for the chip and desired settings.

That thumping noise? Thats me banging my head against a wall

Well, I’ll be the first to admit the pic/C isn’t going hugely smoothly so far.

The C side I’ve picked up (Re picked up as did C++ way back ??) as that’s easy enough.

 

The side I’m having well.. frustrations… with is the various peripherals and libraries for the XC8 compiler for the Pic.

In a nutshell, discrete libraries for the peripherals have been replaced with the MPLAB Code Configurator – which, I can understand in some ways as otherwise there are a LOT of libraries as you need to cover all the supported chips the code configurator is missing something important from Microchip. Straight forward examples and instructions on how to use the damn thing.

 

I’ve located some tutorials which will form the basis of what I need, as I know what I want the various peripherals to do and once it well.. ‘clicks’.. it’ll be straight forward, and it’ll click once I’ve wrapped my head around the code configurator as then I’ll be able to setup & code libraries for the particular chips to do what I want them to do.

And you can be sure I’ll be including the things in the open source release when it’s eventually ready for the Pic circuits.

 

I guess the main frustration is a lack of clear documentation for things like Serial communication via the Usart module and Modulating a PWM signal via the CCP – I know how to do the latter in theory due to getting it working on the picaxe – The bit I’ve not idea is getting the serial data to the USART module.

Building the signal is straight forward, as the relevant module has 2 inputs – it’s a case of setting one input to the pwm signal for the carrier, and then switching the other input between the PWM for the hit signal and the serial data.

 

In all honesty, once I’ve got my head around the serial data transmission/usart module it’ll be pretty much gravy from their on out.

 

Ok, so rant over 😊

 

In the meantime I will be updating the Picaxe based circuits for the previously mentioned updates and having more thoughts on the medic system – It’s meant to be pretty much optional, so why include too much on the sensors. The Timing can be done on the medic boxes themselves and then just zap the sensors to auto reset when it’s done – THAT can be done on the current picaxe based sensors as it won’t take a large amount of code/space and translated to Pics when that version is up and running.

Audio module wise, I’ve got the usb based modules, though the only datasheet I’ve located is in Chinese so I’m working with a somewhat ropey auto translated copy. It suggests that it needs a program to convert from Mp3 to .bin files and upload them to the module, BUT at the same time it’s using the same core chip as the sdcard based audio module so should be able to read mp3 straight off – the main difference seems to be the storage media (onboard memory versus microsdcard), well.. That and the onboard amp – 1W compared to 3W which could also be an issue.

Worst case with that is we stick with the existing modules, which isn’t the end of the world even if it does up the cost slightly for needing the microsdcards (Which are reusable though)

Updating sensors and going forwards

So, today I’ve been looking at alternate chips for the sensors, as to add the extra medical and reporting systems to the current sensors based on the Picaxe 08M2 is really pushing the envelope of what it can do.

August Arcturus update

Well, it has been a little while since last update, but then, there hasn’t been a huge amount to update yet as real-life & health reared it’s head for a little while over the summer.

That hasn't stopped planning and work on Arcturus overall though.

I did tinker with LCD/Oled displays for Arcturus to add info , but I’m not happy with how they are handled via picaxe basic so they will need to be something I work on in C, which I’m partway through getting up to speed with.

However, that hasn’t stopped work on the existing Arcturus system sensor and emitter prototypes.

The sensors have had a quite extensive upgrade following the feedback at Babylon 5, along with implementation of the various effects – The problem now is the chip being used in the sensor (Picaxe 08M2/PIC 12F1840) is running critically low on code space. So to include a medical system/medic box could possibly need switching to C, which I think would give some efficiencies over picaxe basic or move to a chip with more available resources – a move that would effectively mean the existing sensor mk1’s/prototypes would migrate to crew/monster sensors as they are unlikely to need the full medical system included and wouldn’t need the smaller chips replacing..

That said, when it comes to a medic box/medic system and building it into sensors, then the design is pretty much locked in, admittedly as an option extra/bells and whistle. A thought regarding that I’ve had is to have the medic system including settings for whatever variables – anyway, that’s more something for another post once there has been more thought/discussion about it – what I’m not wanting it to do is remove the chance for roleplay around injuries, and use a medic box more as an ultra-tech or magical healing system to go alongside bandages and duct tape 😊

The coming bank holiday weekend will see the pretty much production power level emitter circuit being tested with a ppg body and 16/14mm lens. Curious to see how the output comes out on that one 😊 Along with the updated sensor for feedback around it’s user-friendliness.


Following that, and given that at the moment there isn’t really a need to change the emitter/sensor code from Picaxe to C as yet, the next stages, prior to publishing the information will be:

• Add two optional inputs to the emitter circuit – 
• one to change between ‘lethal’ and ‘stun’ settings and one to switch between semi-auto and full auto
• 5 versions of the code – 15,30,50,75,Unlimited magazine/ammunition sizes
• “pump action circuit” – basically for those that want to simulate pump action gear, like the Aliens pulse rifle or similar – 
• This would basically be a 7-15 ‘round’ capability that requires a pump action to reset after each shot, then a longer full reload (Probably triggered by holding a reload button and pumping at the same time)

Other possibilities:

Setup mode – basically it uses the Arcturus code to say what the various settings on the emitter circuit are including magazine size, and the various settings – I envisage this being used really only when shooting a ref box for testing or similar, but it would be an idea to include in the basic circuit I think.


Ref or Referee/GM/God boxes would be combined emitter/receiver circuits with displays that allow refs to set sensors and check sensor settings (I.e. zap a sensor and it verbally reports).

A Ref box would be the only way to enable a sensor to take multiple point damage as well, as rather than 2 versions of the code, I feel it would be easier to default to having it disabled, but with the option of enabling it for those that do want to include multiple damage.

Would it leave the possibility for abuse – maybe. But it’s also something I think would benefit from needing a physical connection via say a usb plug/cable to enable so for example, it would not be possible to make an emitter circuit/gun that say in one shot enables multiple damage on a target sensor and on the next hits it with multiple damage when it’s a single point damage game.

It may sound extreme, but I’m trying to cover as many concerns as I’ve been able to come up with as possible.

I also see a ref bax as a method to enable certain immunities (Say to radiation damage) for monsters though this is still in the air – Medic boxes however, could be used to add temporary immunities to radiation damage ot toxin damage – representing various drugs or even full biohazard suits etc.


All still in progress, but the basic level gear won’t be long before I sit down with the documents and try to convert a lot of notes into something legible 😊

update and bookings

As booking for Babylon 5 : Fall of light, game 2 will be opening shortly, I figure a quick update is a good idea:

I'm busily working away in the forge, updated and creating the Arcturus system and updates

It TOTALLY looks like this....

The Mk2 PPG circuit is about ready and has a different output stage to the Mk 1 so the code won't be compatible with the Mk1 circuits due to this.

I'm planning on updating the Mk1 circuits (The  version in the current documentation) code to bring them in line with something planned for the Mk2, as there's a stock of Mk1 circuits out there now.

Updated documentation for the Mk2  PPG's will be published by the end of July all being well.

Baseline sensors will be around the same time.

Medic and Ref boxes will take a little longer as the planned displays with the picaxe are a little limited so I will need to switch to C for these, bar a proof of concept version using the fairly expensive displays setup to be used with the picaxe chips.
that said, I'll likely post the information for the proof of concept medic & ref boxes while refining them for the future.

Mark 2 PPG board size

Revised PPG board

Well.

Given how much of a “shove it in with a big stick and hope” the original PPG boards were...

I think the revised versions are a tad easier to fit in:

Plenty of room now...

Overall progress

So, quick progress update on the Arcturus system. Now no longer Project: Arcturus now the Arcturus Larp Combat System

Feedback & forwards.

Well, I'll admit I'm a little surprised.


I've been working primarily on two things  since B5 - Data transfer and refining the circuits.

WIP & Refinements

Curently, now the Sensors have been updated following the feedback from Babylon 5, I’ve started working on one of the refinements to the emitter circuits to make them a little cheaper (less componants) before fully publishing everything.

It can be summarised as changing the way the signal sent to the IR emitter is generated.

The current circuits, PPG and in-development use an EXTERNAL signal modulation method – this is the easiest to code, but needs additional external componants.

In this it uses the PWNOUT command in picaxe basic to generate the 57.6kHz carrier signal on 1 pin, and the 1800hz “Hit” signal on a different pin. These two signals are then fed into an external AND gate made from transistors and then, (depending on power output desired) fed into a Mosfet to drive the emitter.

For the data signal, it replaced the hit signal output on the pin with the serial data output after 50 mS, using the Picaxe basic command to generate serial data via the software on any pin. Relatively simple and working fine now.

The refinement in development however takes advantage of some of the modules built into the PIC chip that is the core of the Picaxe to output a fully modulated signal on a single pin, without needing the components for the external AND gate – the payoff is it’s more difficult to code.

In a nutshell –

It tells the PWM module that generates the PWM  “carrier” and “hit” signals module to not output to the physical pins

Then tells the Data Signal Modulator to use 2 PWM module outputs above as the input.

Triggering the signal is a case of switching the ”hit” signal generation on or off depending.

For the data signal, it’s a case of telling the Data Signal Modulator to use the serial signal instead of the Hit signal

The part I’m currently working on is the switch between Hit signal and Serial data signal - I’ve got the serial data outputting on the Serial out pin. I need to get it switching off the physical pin output for the serial code and also changing the source for the 2^nd input to the data signal modulator. I’m hoping to have it done by the end of the weekend.

Overall though in the end it’ll be worth it, as while the external modulation is quite simple to code, it is a little more expensive components wise, and this is essentially a refinement to get the costs down

Finally....

Well this has been an odd weekend.

Problem found with the mosfet circuit (see prev post for video) is down to the logic gate on the breadboard be8ng configured as a NAND gate rather than an AND gate, which meant the thing was on all the time... Which is a bit of a bugger when the resistors are specced to on,y deal with the amount of power in short pulses.

Hey ho. Sorted now.

Now I’m finally getting round to updating the startup sequence for the sensors based on the feedback at the game....

See you on the other side....

Not a productive day.....

Well, today I picked up m new bench power supply, meaning I can get on with the higher power output circuits, driving the emitter at 1.5A.

Somehow, I don’t quite think I’ve locked that particular circuit down just yet.

There’s a lovely smell in the workshop though.....

Woohoo!

So,

Little bit of an announcement today: As mentioned here I was going to have to re-invent the wheel with a data transfer/WoW pulse signal.ess

As of last night... we have success!

 And given it's based on the pre-existing code I'd done that was compatible with WoW, DoT and Lotna sensors, It still works with everything it did before, as well as WoW and Dot baseline (In that it recognises a 'hit' has come in AND the emitter version works with baseline Wow, Lotna and DoT sensors as well.

Now to sort out the little tweaks to the startup for the sensors mentioned in the last post then its documenting time for the basic stuff and refining whats going into the data system.

TTFN
Ady

Now the dust has settled.....

Well. The Babylon 5 game has been and gone now, so time to start working on future stuff.

 

Bit more of a text wall this time…

Jan update...

Well I know it’s been a little quiet around here recently, but I’ve not been idle. 

With the game at the start of April, prop production has shifted to high gear (No spoilers I’m afraid).

But here’s a pile of Ppg circuits just waiting for their processors...

,i

For my next trick, after adding the processors and checking for any solder boo-boo’s  it’ll be time to break out the small toolkit and fit the boards int the bodies

And honestly..... doesn’t feel like I’ll need one of these one of these:

Ttfn.

Ady