1011001011100010101 etc.....

 So, it's been a few weeks since the last update, and overall, while there has been progress, it's also been a case of two steps forward one step back regarding the Arclight(nee Arcturus) signal transmission.

 

From previous, you'll know the plan was a 50ms pulse @ 1800hz followed by 5 bytes of serial data. 

This was done by outputting a PWM signal at 1800hz(50% duty) via the CCP module in PWM mode, then after 50Ms switching to the output from the Eusart module to transmit the serial data.

 

On the picaxe, this worked. It could be transmitted and received.

 

When switched to a Pic, it didnt. A lot of time was spent working on this and working on WHY it wasn't working - on the principle that "It works on X, so why not on Y"

It turns out that a lot of people where having similar problems with Eusart modules when they are transmitted over IR. Wierd but hey-ho. Mind you, those modules were only ever intended to trsansmit data over wires.

 

But wait... it works on the Picaxe Chips....

Yep. it did. And I think I've figured out why.

 

Now, the Picaxe chips are based on PIC chips (You can revert them back to pic chips if desired, but can't then reset them back to picaxe). I was using the Pic 08M2 for the sensor and the 14M2 for the transmitter. The relevant pic chips underpinning each are: 08M2 = Pic12F1840 POicaxe 14M2 = Pic16f1825

On these two Pics, the output pins for the Eusart modules, as well as being able to be fed into the DSM module to create a modulated signal are on a set output pin, which can't be changed.

The PICAXE chips have two serial output and two serial input commands. SERIN/HSERIN and SEROUT/HSEROUT to input/output respectivley. I was using the SERIN/SEROUT commands, which looking through the details of each commands, and the fact that Serin/Serout use different pins than the fixed pins on the Pic leads me to beleive that these, while using part of the hardware Eusart module, also have a fair amount of Firmware wrapped around them, and as such, don't quite work the same way.

 

And that's the difference. 

I suspect if I canged the Picaxe output to the HSERIN/HSEROUT command that the transmission would likely fail as it does on the Pic chips.

 

Bit of a bugger really.

 

So... how to get around it?

 

More research followed, around the various IR transmission protocols that are out there in the world, and the majority all work on a similar priciple. That of a variant of Pulse witdth modulation. In this, a signal is sent with varying duration pulses, and the length of each pulse dictates wether the pulse represents a binary '1' or binary '0'. These pulses can be sent at a set frequency or not depending on how you set it up.

The drawback is you have to manage the pulse width yourself - "Bit-Bang" the data in common parlance, which needs a chunk of calculations* for both transmit and receive setup.

But the priciple is straightforward, and I can also transmit the data at the 'classic' 1800hz so that legacy equipment (WoW gear, and the kit made for the Bab 5 game) will see the signal as a single hit, and Arclight sensors will see their signal as a single hit. Will it work with other systems that have grown from the old WoW standards? Don't know. If they look for the 1800hz 'hit' signal by counting pulses then probably, but I beleive the data part will be ignored. If they check the frequency by checking the pulse width, then it'll likely not work. Still, don't know as I haven't got any of the kit to try it with, and, if I'm honest, I'm only including the 1800hz frequency in to support the Picaxe based PPG's that were made for Babylon 5.

 

Still, overall despite effectivley taking a year off developing anything, it's coming along nicely.

I think I may be going a wee bit potty.....

 

I think I'm going nuts.

 

In this case, last night I was having a problem with a Pic chip.

 

I'd changed the output pin for one of the serial communication modules. nothing flashy, done it before.

 

 The problem was, it appeared to be giving an inverted output on the original pin as well....

 

 

 

 

 

Yellow trace is the output I want, red trace is the old pin - Inverted output right?

Weird right? 

 

I couldn't find any reference to it anywhere, so several hours later I give up and go to bed.

 

 

This morning, I rock up with a cuppa... I turn everything on.

 

That's it.

Nothing else.

 

 

It's bloody working.

 

 

We ain't dead!

 

 

Nope, we’re still here and kicking around, despite having a "smal"l break over the 2^nd half of last year – though I think given the year it was…. It’s hardly a surprise

 

Still, development has been going ahead now, Oled display drivers are working

 

And Bluetooth based comms are up and running, as is development on pc based sections as well… once I’ve wrapped my head around GTK+ toolkit for the Gui side of things. (That has the added advantage of working with both Linux and Windows unlike some of thither gui tools).

That’s especially handy now I’ve finally been able to move all the development tools to a Linux platform (My preferred OS for many years now) 

 

 The only disadvantage is the Hantek oscilloscope software, while working perfectly well is a little harder to make out parts of the display. Still, that’s a minor issue, soon to be solved with the purchase of a spanky new ‘scope for myself

 So yeah…. While this time last year we had tentative plans to be showing something at LarpcCon 2021…. Circumstances have conspired to kinda shoot that down Current (tentative)  plans are to have something spanky put together for LarpCon 2022

 

We shall see.

Post Larpcon comedown

Well...

It's been a little while since LarpCon and in all honesty - I think it went well, it was certainly interesting for networking and spreading awareness.

The only real issue was it felt like the venue is getting a little small for it, and it was only a month until the next game - we were advising that we are planning on running next year as well. Mind you, the next game has now been postponed until December...

Equipment wise, lots of chats. Including some around using an Android app as the medic/ref boxes, which I've looked into and it's either a lot of faffing to get the sensors/emitters to communicate via USB protocols, plus costs to just sign up to the Android store so that apps may be downloaded. Overall it's been given up as a not-economically-viable-at-the-moment option.

What I am going to do for the sensors is enable them to receive the information from medic/ref boxes via IR or possibly via an additional UART module that uses usb sockets and cables to connect to the  boxes,  but not using USB protocols, just a handy, readily available connector set and add a small, relatively cheap Oled display. It's just a matter of finding a suitable PIC chip and sitting down to figure out and code.

The emitter ciruits are going to get the option for a similar usb socket to enable them to be updated via ref boxes to different damage/damage types - I'm picturing this more for Crew kit to give maximum flexibility for the circuits.

There was also talk around adding a nextion touchscreen to the sensors as I've found a source for reasonable sized ones for about a tenner each. BUT that's still adding a tenner plus to the cost of each sensors, along with higher current requirements for the battery. So that has gone out the window :)

However, a touch screen display for the Medic/Ref boxes on the other hand.... That's a thing that can be done, as can a small display for the sensors as well.

LarpCon definitely helped get the creative juices flowing and kick me out of the little bit of a funk I'd gotten in around the Arcturus gear.

Additionally there has been a rather handy video from Larpcon posted:

If you fast forward to 02:54 then the kit may look and sound familiar :)

Time flies & Larp-con

Oh blimey......

Where does time go?

Still ,nothing much to update as yet, though I will be at Larp-Con 2020 this coming weekend .

Come find me - I'll be in with the promoters - Look for Starlore/Babylon 5: Call of light and I'll have some of the basic level kit with me :)

Come & Find us!

TTFN

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 😊 )