Showing posts with label Arcturus. Show all posts
Showing posts with label Arcturus. Show all posts

Monday, 21 October 2019

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

Tuesday, 1 October 2019

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 1st 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 😊

Sunday, 9 June 2019

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

Wednesday, 17 April 2019

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

Tuesday, 16 April 2019

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…