Master/slaves StampDAQ serial comm quirk

R. Kinsler

Hi all, newbie here would appreciate a little help.

I'm working on a project where I have one BS2 acting as a Master, with two other BS2's controlling slave Units. The slave units have LEDs that light up in sets. The lighting of a particular set of LEDs·signals the user to press a particular button. The slave unit is counting from the start of the lighting of the LEDs to the press of the button (eventually this will be an approximate time in milliseconds after the appropriate conversions). Once the button is pressed and the slave stops counting, data is sent to the Master (the slave Unit number, the pin corresponding to the button, and the count time). The Master receives this data and the relays it to the Stamp DAQ software via the serial cable. The reason for having the Master is so that the slave Units can operate basically independentally, but I only need a single serial cable to collect data from both slaves operating at the same time.

I have connected the Master/Slaves configuration similar to how it is shown in the Nuts & Volts column #81. In general, the circuit seems to be doing what it is supposed to and I am getting good data once the buttons are being pressed. The trouble I'm having is the lull between the start up and when the count times are being collected.

The Stamp DAQ·output should look something like this:


But sometimes I am getting some garbage at the beginning (before the first button press) that looks more like this:


The line with UNIT 0, PIN 14, and Reaction Time 254 will just keep repeating until the first button is pressed. This doesn't make sense because there isn't a PIN 14 in the data set. Does anyone have any idea why this is occuring?· I am attaching the code for the Master program and can also furnish the code for the slave Units if requested.

Thanks in advance and sorry for the long post...

Martin Hebel

Since it's very improbable there is an issue with the code you posted in sending data to StampDAQ, I suspect the problem is here:

SERIN 0\1, Baud, 5, UnitII, [noparse][[/noparse]unit1, pin1, TimeCounter1]

What does the code look like on the other side to populate these variables?· I suspect there's a timing/bit issue.

-Martin




▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
StampPlot - GUI and Plotting, and XBee Wireless Adapters
Southern Illinois University Carbondale, Electronic Systems Technologies

R. Kinsler

Martin,

I am attaching the code for one of the slave Units. The only difference in the code between the two slave units is the assigned constant for unit (0 for Unit I, 1 for Unit II).

I think the communication with the Stamp DAQ seems to be okay. It just seems to be getting some strange inputs from the Master before that first button is pushed. I'm wondering if I'm missing some kind of statement in the Master code to keep it from sending that·garbage to Stamp DAQ? Please excuse the inaccurate language, my programming is self-learned and I may have made some kind of glaring mistake somewhere...

Thanks for the response.

Just editing to add:· I have flow control pins for all connections between Master and slave Units.

Martin Hebel

Sending 3 bytes, catching 3 bytes... if the timing is just a bit off it could result in garbage.· One thing you can try is to reduce the BAUD rate used for your master/slave comms.· A send thing would be to send/receive the data as ASCII instead of binary.

SEROUT 14\15,Baud,[noparse][[/noparse]DEC unit,CR, DEC pinz,CR, DEC TimeCounter,CR]
 
SERIN 0\1, Baud, 5, UnitII, [noparse][[/noparse]DEC unit1, DEC pin1, DEC TimeCounter1]

The CR's between each set of values may help keep the data synchronized better.

Anyone else have any good thoughts on this one?

-Martin


▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
StampPlot - GUI and Plotting, and XBee Wireless Adapters
Southern Illinois University Carbondale, Electronic Systems Technologies

Unsoundcode

Increasing the timeout value·to maybe 10 milliseconds should help, start high and come down with the value.

·UnitI:
··· SERIN 0\1, Baud, 10, UnitII, [noparse][[/noparse]unit1, pin1, TimeCounter1]

the same for UnitII

Jeff T.

EDIT Hmmm maybe not......I was taking a look at this problem and taking pieces out of the equation and thought the timeout time was too short, looking again I believe its something to do with the flow control pins 1 & 15. Do away with them and the problem dissappears. For this I cannot give a reason.

Post Edited (Unsoundcode) : 3/6/2007 7:53:19 PM GMT

R. Kinsler

I tried sending the data as ASCII with the carriage returns, and it seems to have to worked. I'm not getting the garbage at the beginning. Perhaps the format change prevents the·Master from mistaking incidental values for real data? Whatever the case, it seems to work.·I think I will also look at·manipulating the pause time. I'm a little wary of removing the flow control pins because there is so much chatter going on, particularly for the Master unit.

Thanks for the help!