Tuesday 13 April 2021

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.

Friday 5 March 2021

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.
 

 

Wednesday 10 February 2021

We ain't dead!

 

 

Nope, we’re still here and kicking around, despite having a "smal"l break over the 2nd 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.