45 replies to this topic

[pyromaniac303]

Just gauging interest and collecting some thoughts on a project I have been working on for a long time:

 

I have been developing a modular firing system using an automotive 1 wire comms interface (LIN bus). It supports up to 128 units each with 20 cues, it reads a script file in .csv format (editable in excel) from SD card, and has a minimum cue to cue time of 0.1 seconds. Each unit can be polled for connectivity, and each cue can be continuity tested and reported back to an LCD on the master.

 

I'm hoping to release the master software as open source for the Arduino platform, possibly sell a shield to make construction simpler, and sell the slave units (these are PIC based and all surface-mount, so would be awkward to build for the non-technical). This way I hope to get around some of the liabilities incurred with selling a complete system, i.e. what happens if someone were to accidentally fire a cue and cause damage or injury.

 

The slave units are mounted in a waterproof diving box approx 200mm x 120mm, the panel has speaker terminals like the ones pictured, however the PCB will take up the entire box and the edges will be silicone sealed (current prototype is MDF to save PCB costs during development).

 

The components will all be located on the bottom side of the panel, and conformal coated to prevent moisture damage if it does somehow get past the silicone. Each unit will have 2 panel mounted 3.5mm headphone-style connectors, which will be plugged with a rubber bung when not used, for ingress protection. The 3.5mm connectors will carry +12V, ground and signal to each unit, and they can be daisy chained. The great thing about these cables is that you can buy them very cheaply (i.e. £2 for 20m from eBay), and each unit has a fairly large capacitor therefore cable resistance does not become a problem on normal firing sites of less than 40 metres, this is the guaranteed working limit of the LIN system anyway. The capacitor charge time over 40 metres of poor quality cable is still less than the 100mS between cues, so if someone had shorted an output connection by mistake and the unit went into reset, it would be 'alive' by the next command and would not miss a firing instruction.

 

Each unit has to be bought with an address in mind, so for most users 1, 2 and 3 would be appropriate for 3 point firing, though for those that always mirror the left and right sides they may wish to buy 2 of address 1 for the outers, and 1 of address 2. The alternative to this would be that the user buys a PICKIT2 for around £30 and uploads their own code into the slaves via the test points.

 

The key thing with this has been to keep it within reach of hobbyists, so I am hoping to sell these slave units around the £100 mark, this would include support in getting the master that you'll have built yourself working successfully. I envisage the master shield to cost around £60 including LCD and card reader but have not done cost calculations on bulk purchase yet for this.

 

I will be placing a sample order for 100 sets of parts in the near future, and would like to see if I have missed any crucial features / obvious improvements I could make at little or no extra cost. I would also like to know if people think that the price is acceptable for the slave units.

 

Pictures of prototype unit - note that the final build will be all FR4 PCB top panel rather than MDF, so the connectors will be soldered directly in rather than wired. The 3.5mm sockets will also be panel mounted rather than loose on wires.

 

Sorry for the gigantic post but I would appreciate any questions or comments you may have.

 

Paul

 

 

[phildunford]

This sounds brilliant!

 

Is there a way to sync this to sound? I've made similar devices, but the complexity of sound sync software has always been beyond me - except for using a midi click track or similar,

 

It would be good if the units could be locally addressed. This way if several users got together they could create a bigger system.

 

I would think a clear disclaimer with any parts sold would keep you safe legally.

 

An Open Source project of this type would be a boon to many of us who can not afford propriatory systems.

 

Very best of luck with this.

[pyromaniac303]

Well the protocol is very simple (It is not fully conformant to the LIN standard, I just used the transceiver devices), it consists of 3 bytes -

 

To fire: A module number  1 to 128, a cue number and the complement of the cue number for error checking.

 

To continuity check: A module number 1 to 128 +128, a cue number and the complement of the cue number for error checking. The module then responds with 0 or 1 depending on the cue state.

 

To poll (check which modules are connected): A module number 1 to 128, 42 (0x2A), 213 (0xD5). The module responds with a 1 if it is present.

 

Using an android device with a bluetooth serial port you could easily put together a master unit that would also play music in sync. You could even do this in App Inventor for those with no programming experience. I may get round to this eventually, but all source files/schematics will be available for the existing system so users are free, and encouraged, to build their own compatible accessories. I didn't want to go down the route of time code/IRIG input, as that was really beyond what I set out to do.

 

Well the problem I have with addressing is that it would add reasonable extra cost to add a selection device (e.g. binary coded switch) that is weatherproof, and I don't think that jumpers and pins are robust enough to survive a firing site. Also I have no remaining I/O on my microcontroller. I will publish all 128 address files in .hex and .asm format for people to flash their own micros to change address. PICKIT clones can be had on eBay for around £20 and are fairly simple to use. Additionally if people have several of the same address field modules in the same show, they could add a 4th address byte in the master software and build an addressable host controller with several separate outputs.

 

Forgot to mention in the post above - the power source is 3x 18650 lithium ion laptop cells in the master, giving a nominal voltage around 12V.

[Bob Twells]

Sounds like you've put a lot of effort into this, great work!

 

I'd concur with the above points about addressable units. If you are relying on them for business you're likely to want to have at least one spare module in case on gets damaged or goes wrong. In this case you'd need a spare for each of the 'channels' if they are not reprogrammable, which might put people off.

 

Like Paul says, even a manual switch inside the unit is better than nothing. However as you have a signal line going in, could they not be programmable? I.e. you connect a single slave to the master and can program it's channel number.

 

Pricing sounds very good compared to alternatives, and the diving cases are definitely a must with our weather. Also makes them looks very professional!

 

Look forward to seeing some plans and code

[megabusa]

Nice work Paul, makes mine look a bit shoddy !

 

As said above, the ability to re-address modules easily (ish) is important.

 

Also, I can't tell from the pics, but it looks like you have used a common ground to the outputs ?  If not & you are using X & Y addressing method, I can't see any diodes on each cue ?

 

Must get round to posting pics of mine.

 

 

Cheers,

 

Phil.

[pyromaniac303]

I'd concur with the above points about addressable units. If you are relying on them for business you're likely to want to have at least one spare module in case on gets damaged or goes wrong. In this case you'd need a spare for each of the 'channels' if they are not reprogrammable, which might put people off.

 

Like Paul says, even a manual switch inside the unit is better than nothing. However as you have a signal line going in, could they not be programmable? I.e. you connect a single slave to the master and can program it's channel number.

Yes I see your point, especially for use by companies rather than individuals where equipment just gets loaded into the van and things can get overlooked.

 

In theory we could use one of the blank cue numbers (i. e. greater than 20) to initiate a 'set address' mode, however the PIC16F722 I'm using does not have an internal EEPROM or the ability to write to program memory, so any address changes would be lost as soon as you unplug it! May look into a one wire interface EEPROM like the 11aa010 and try to free up an IO line somehow to store the new address value.

 

Its not arranged in a matrix Phil so no need for the diodes, I decided on one output to one channel system for simplicity. It is grounded via a low side driver to select between continuity test and fire modes.

 

Will do some tests on the batteries at various temperatures. I'd imagine they'd be ok, I use them in my 3W LED head torch and managed 3 November shows without a recharge.

 

Thanks for your comments,

Paul

[Bob Twells]

Some more techy questions:

 

You mentioned the units can be polled for continuity? Is this per physical unit or per channel? I.e. if you had two 'B' channel boxes, can you check them independently?

 

Have you done tests on number of igniters per cure that can be firer in series and parallel, and can cues be fired simultaneously?

 

Have you built any kind of master unit yet?

[Bob Twells]

I know nothing about LIN really, so forgive me if you've been through all this, but could the auto-addressing features be of use? (http://en.wikipedia...._autoaddressing)

 

The "Extra Wire Daisy Chain" method could be useful, so the order in which modules are daisy chained from the master determines their IDs. You can get 3.5mm plugs with 4 contacts pretty easily, although the 4 core cable would therefore be less standard and probably a bit more expensive.

[pyromaniac303]

 

You mentioned the units can be polled for continuity? Is this per physical unit or per channel? I.e. if you had two 'B' channel boxes, can you check them independently?

 

Have you done tests on number of igniters per cure that can be firer in series and parallel, and can cues be fired simultaneously?

 

Have you built any kind of master unit yet?

 

There are two test modes:

A module check (to check that an address is physically connected on the bus - for testing all your modules are wired in).

A continuity check. To do this you select the address you wish to continuity check (1-128), and it tests each cue and reports all 20 cue states back to the master. If you have more than one module on the same address, you must connect them individually during testing.

 

I have built a bit of an unpresentable master unit currently out of a prototype shield, and attached the buttons/LCD to some old cardboard! I have a case ready for it but am unwilling to cut any sort of panel til we're 100% sure of all the features everyone wants. Needless to say it shows everything working and reading from an SD card .csv file with 0.5s cue spacings, so here it is:

 

 

I think that auto-addressing would confuse people in the field, and make the software a headache for people to understand (myself included!). I have ordered a sample quantity of the 11aa010 EEPROMs so that unit addresses can be changed using the master, and will have a play around with it over the next few months.

 

For those of you fluent in assembler for PICs, here is the latest slave source file:   722 v1.txt   22.42KB   917 downloads for use just change the extension to .asm.

 

For those not fluent in assembler, it works like this:

 

On power up - Initialisation

Continually look for incoming bytes - if received, check for errors, if no errors, store it in variable 1 and start a timeout of 20mS.

Continually look for incoming bytes, whilst ensuring the timeout has not occured. If one is received, check for errors and store in variable 2, reset the timeout.

Continually look for incoming bytes, whilst ensuring the timeout has not occured. If one is received, check for errors and store in variable 3.

Check variable 2 = 255 - variable 3.

Check variable 1 = address, if so go to fire mode. If not, check variable 1 = address + 128, if so go to test mode.

 

Fire mode:

Check byte 2 against cue number (1-20), fire appropriate cue (high for 30mS). Also if 42, send '1' back to master as an 'alive' check to see which addresses are connected.

Go back to looking for incoming bytes.

 

Test mode

Check byte 2 against cue number, test appropriate cue (set cue output high whilst ground-side low side driver off, test if input goes high).

If it does, send out a '1' over serial. If no continuity send a '0' back to the master.

Go back to looking for incoming bytes.

 

I haven't done tests on maximum igniter count as I am changing the output MOSFETs. I initially used an automotive high side switch (BSP452) with a thermally limited current of around 1A as I had a few hundred of them spare, and the system was intended for personal use when I ordered the first boards in 2012 therefore would have been 1 igniter per cue only. Now my plans have changed - I want to make it more accessible and cheaper therefore I am changing to a -4A TrenchMOS P channel device and a DTC114EKA pre biased NPN transistor to drive it direct from the PIC output. Got samples of several MOSFETs to trial run by lashing on to the existing boards for testing. I am hoping I will get the chance to play around with a thermal camera soon so will be able to check if they're getting hot at peak current.

 

Also do any talented software developers (preferably VB 2010 so I can follow it) want to have a go at a serial port control application to fire directly from the PC? I shall make the serial port to LIN adaptor complete with battery pack free of charge for whoever wants to attempt this, and can give you it at the AGM. The prize for getting a nicely working system will be a couple of slave units.

 

Edit: Serial port to LIN adaptor will be a USB to TTL level converter (CP2102 etc). that installs its self as a serial port, so fear not people with PCs less than 10 years old...

Edited by pyromaniac303, 18 January 2014 - 11:26 PM.

[pyromaniac303]

Yes the interface may change somewhat. On my list of interface/LCD changes are:

Key switch to unlock fire mode, with red LED to indicate system is armed.

Formatting of time whilst firing - currently in mS rather than minutes, seconds, 0.1s.

Battery voltage monitor on home screen.

[whoof]

Yes I see your point, especially for use by companies rather than individuals where equipment just gets loaded into the van and things can get overlooked.
 
In theory we could use one of the blank cue numbers (i. e. greater than 20) to initiate a 'set address' mode, however the PIC16F722 I'm using does not have an internal EEPROM or the ability to write to program memory, so any address changes would be lost as soon as you unplug it! May look into a one wire interface EEPROM like the 11aa010 and try to free up an IO line somehow to store the new address value.
 
Its not arranged in a matrix Phil so no need for the diodes, I decided on one output to one channel system for simplicity. It is grounded via a low side driver to select between continuity test and fire modes.
 
Will do some tests on the batteries at various temperatures. I'd imagine they'd be ok, I use them in my 3W LED head torch and managed 3 November shows without a recharge.
 
Thanks for your comments,
Paul

Hello Paul.
Not sure if this helps but re the address issue.
I have used an adressable logging system in the past where for maintenance purposes a pin jumper would change the adress to a known common one.
Ie all units could be set to the same address.
This would only give the option of replacing only one faulty unit in any individual system though.

[pyromaniac303]

Updates - I have received some samples of one wire interface EEPROMs (https://www.microchi...ocName=en535099) and sorting out a robust address-change protocol that can be done on site with the master. I had one I/O port left, so shouldn't affect channel count.

 

Does anyone object to an address change mode whereby only the box to be changed can be plugged in to the master?

 

I am struggling to come up with a method of re-addressing boxes when there are several on the bus, as I think it would be too confusing to identify them - unless each one had a unique serial number, however this would be a headache from a manufacturing perspective.