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.

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…..

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 😊

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…

PPG Files and upgrades

I know it’s been a couple of weeks (ish) since the last update, but that’s because I’ve been busy on things…

However, the good news is that the PPG build documentation and files are now ready, and have been for a couple of weeks.

They have been teste d& work with baseline Worlds of Wonder sensors, Uklta's DoT sensors and Heretik forge prototype sensor

Dropbox link is here (opens in new window) - Updated 18/12/2018

This is a very specific build for a very specific body, which while the circuit can be transplanted and used in other pewpew bodies it is missing a few things that were sacrificed in the name of compactness.

1^st is a button to trigger a ‘reload’ cycle, rather than turning it on & off again

2^nd is more power/current going to the IR emitter to increase the output and increase the range.

The PPG circuit, with the lens assembly in the PPG documentations manages around 30-35 meters, which while above the “in universe” range of 25 meters, is low compared to some of the kit people use.

Personally I think this is quite a reasonable range given how small they are, and how tiny the lens assembly is (16mm lens, 14mm effective due to the mounting) – I’m not sure I’ve seen and kit one with less than a 25mm lens before now – I could be wrong, but I don’t recall seeing any.

---

 So, there are two major “upgrades” that I consider crucial, and one optional one that I’m planning

1: Add a reload button 

A button to trigger the reload cycle (Currently only triggered on  power-up for the ppg) was easy enough to add - but the space just wasn't there in the PPG body. 1 button, 1 resistor and a quick change to the code and that was sorted.

2: Increase output power/Lens size

Now, there are a couple of ways to increase the range for a IR based system such as this:

                More Power to the emitter

                Larger lens & lens assembly.

More Power to the emitter: 

There are some IR emitters out there that can take quite large amounts of current for quite a high powered output, but in line with the design principles in my head I’m wanting to keep the price down as much as possible while keeping it as straightforward as possible(1) so I’m avoiding some of the really snacky IR LED’s that can manage some serious grunt…. But cost £3+ each…..

So, using the SFH4545-DWEW emitters (Often referred to as Gherkins) we have an ideal peak current limit of 2amps.  I don’t want to go higher than this as even at the short pulse duration in use it would risk damaging the LED (and yes, I have blown a couple working on things)

The PPG’s have a nominal max of 800mA due to the restrictions of the AND gate transistors that modulate the carrier and hit signal together, and the voltage regulator is rated to supply 1.5A max anyway.

So, overall, I’m looking at something that can give a power output greater than 800mA but <= 2A max

I’m also going with a 7.2V supply – the idea being the things can be powered from a standard nicad rechargeable racing pack (2)

The limit of the voltage regulator can be avoided by having the Emitter LED  connect directly to the battery power supply

This would then need something that can take the modulated hit/carrier signal and pulse the emitter at up to 2A

Enter the Mosfet. 

After an exciting(3) evening of trawling through datasheets following a tip from Dave I eventually settled on these Partly because it ticked all the requirements and partly because it wasn’t the £3 each of the originally suggested Mosfet 😊

If anything, the mosfet is a little bit of overkill, but it seemed to be a choice between overkill and not enough…. So…

Anyway, with the mosfet needing 1.5V to turn on, and the Emitter needing 2.7V, running off of a 7.2V supply gave me 7.2-(2.7+1.5) = 3V to play with to drive the current through the emitter. Add in a 1.5ohm (half Watt) resistor gives a nominal 3/1.5 = 2A peak through the emitter.

Perfect.

Ain’t getting much better than that without changing the emitter 😊 and can drop the current/output by changing to a 2ohm resistor (for 1.5Amp output) or 3 ohm resistor (For 1 amp output) – which give a possible option of having a small SPDT switch to switch between 1.5ohm and 3ohm resistor for outdoor/indoor-close work to avoid too much power output causing the beam to “splash” – It’s never fun to shoot yourself… Usually it’s considered far more sporting to let the other side do it.

To be fair, to be on the safe side I may use a 1.6 ohm resistor on future/production  boards which will drop the current to 1.8Amp as that should give a little bit of wiggle room for those components that are outside the average. 

Larger lens & lens assembly. 

A larger lens & lens assembly is a fairly simple principle – The larger the lens, the more light it can collect and send “downrange”

I’m currently working on a 25mm lens & barrel assembly, that using the test circuit I knocked together to focus a barrel/lens assembly gives a nice clear spot on the side of the building down the road – given the brightness of it(4), it’ll go a lot further, but I kinda ran out of houses….. But that’s a good 60meteres, and the circuit used was not running at quite the same power.

Next stage is going to be get a barrel/lens assembly printed that includes a picatiny rail mount so I can stuff the thing into a Nerf body, ad a sight and find out just what it can do.

And then do the same with a 30 and 40mm lens, all the way up to 50mm.

 Optional upgrade:

The one upgrade I’m considering optional at the moment will be a more visual human interface for showing the ammunition status – at present it’s a single LED that come son when the ammunition is “empty” and flashes while reloading.

There are enough spare pins on the chip, that I will be able to use one of the to talk to an external picaxe chip(5) that has one job and that’s to display the ammunition status in a more human interface friendly form, be it 2 digit 7 segment LED display (ala aliens pulse rifle).

A bargraph display or anything similar.

As long as the communication protocol between the chips is “standardized” then pretty much the sky is the limit.

But other than that, I’ve not given that option much thought yet as it only cropped into the old melon this morning.

But then given I only finished the first verostrip prototype of the enhance board yesterday, I’m not surprised.

Ttfn

Ady

 

---

1. Yes, I know if I switch to a pure PIC microprocessor, I can reduce a number of the components and do more via code, but it then also becomes to my mind more difficult to explain what each bit is doing, and harder for anyone to “remix” parts
2. Yes, I know about LiPo batteries as well – but I’m not a fan in all honesty – I couldn’t say precisely why, but there you go.
3. This word is a lie… It was dull… Very, very dull.. but necessary
4. And taking into account the peak wavelength of the IR viewer I was using was not the same as the peak wavelength of the emitter, so it will seem not as bright as it actually is
5. Or Pic later as I do plan on moving to Pics for a future project “Project Arcturus”