Digital inputs, bandwith, errors?

Technical Programming
1

[Idly fumes and throws things at the computer. The forum software just lost his message! … I guess this is why we usually write in notepad and then copy and paste? grrrrr]

Gah!

Anyway, back to the topic.

Hey, folks…

I’ve been trying to get digital data from a nifty little IC for our team’s black box into the Stamp via the Robot Controller’s digital inputs, but I’ve run into a nasty little problem: errors! The data stream is literally strewn with errors! (I think they’re primarily single and multiple bit flips, and I’m pretty sure it’s not the IC’s fault, but I’m not positive. I haven’t yet rigged up a test fixture and done a detailed analysis.) Kind of leads to the question, just how much bandwidth can you really squeeze through those painfully slow digital inputs?

I originally figured I’d have the IC send a new data word just slightly slower than the Stamp’s ~40 loops per second. That way, each word would be guaranteed to be seen by at least one loop. I figured there would be occasional errors, for instance, if the RC was reading the inputs right as the IC was changing them, but I never expected anything like this! Regardless of what rate new data is posted at, about 1/10 to 1/20 of the data words are corrupted, with a very erratic distribution vs. time. Most of the errors are caught by a single parity bit with the data, but the errors are so frequent that many pass the parity check anyway. …Which is not good for the robot!

I suppose I could always do like Wild Stang did and send the data words a few times in a row and take the best out of two or three, or whatever, but that’s a terrible waste of bandwith. Since the RC’s sooooo slooooooow to begin with, every drop of bandwidth and speed is precious.

Does anybody have any experience with this sort of problem? Anyone have any suggestions?

Thanks a lot! :ahh:

–Micah Brodsky

2

What we found is that the digital input pins seem to be inconsistent when they’re latched. Basically, if your incoming data changes at the instant that the RC is sampling the digital ins, they will be corrupted. We tested this by wiring a switch up to all the digital inputs and then running a loop that just prints out the values read. Since 1 switch is connected to all inputs, they should all change at the same time, right? Well they don’t. And there’s no rhyme or reason to which ones change first. So my advice is to see if you can find a way to cause the inputs to not change when the values are being latched.

3

I am not an electrical person but my thought would be to toggle a relay output and us that as a clock for your IC. Then time it so you will know when to change the values of the IC. I really don’t know if that will work but that is my thought on the matter.

4

You have a “race condition” when your data is changing. Well known problem.

First off, you should use a high current bus driver between the micro and the RC, to insure that the line capacitance isn’t slowing the bit changes.

Second, on some micros rewriting a its output with the same number CAN cause microglitches in the outputs. Therefore avoid rewriting the SAME value to your black box outputs if it has NOT changed. Queue new value in the Black Box, and compare with the current value presented. ONLY rewrite the output leads if the data has changed.

Third, you need ONE OF:

A “data valid” (DV) line to the RC,
OR
A handshake line pair between the black box micro and the RC,
OR
A single Request Pulse Sync line from the RC.

DV method:

Whenever the data is about to change, drop DV, toss in a few NOPs (No Operation opcodes) in the micro’s program to let the ringing stop, THEN change the value, wait a few NOPs again, then raise the DV line. Now you’re GUARANTEED that data will NEVER be changing while the DV line is high.

Now in the RC, read the port and the DV into TEMP VARIABLES. (NEVER overwrite the last known good one in your program until you’re SURE it is good). If the DV line is high, you KNOW the data are good, and transfer it into your real variables. If DV is low, KEEP the last good value(s) intact (toss out the temp values) and try again next time around. ONLY update the real variable in the RC program when you’re SURE you have a valid input, and that’s guaranteed to be when DV is high.

ADVANTAGE: NORMALLY you have only one loop time latency for data transfer.
PROBLEM: If your micro’s update rate is EXACTLY some multiple of the loop time, you COULD get into the rare problem of “Beat Frequency”. The RC could never see a high DV, because you’re always updating it at the time the RC reads it.

Handshake method:

Create a line pair between the black box and the RC, “request” and “valid”. Both are low initially. RC raises “request”. Black box puts data on and raises Valid. Once RC has it, it drops Request. Box drops Valid. This is ALWAYS guaranteed to work.
DISADVANTAGE: It takes a few loops times to run the protocol, limiting your bandwidth (unless you have more than one SERIN/SEROUT in your loop).

Pulse Sync method:

You can synchronize your updates to the loop time “heartbeat”. RC has a “Pulse Request” line toward the black box. The RC toggles this line every loop at the TOP of the loop (you’ll need a SECOND SEROUT statement to get that out. Use old values from the last loop for everything else). The Black Box has a one value Queue inside of it.

You know the RC will be busy immediately after togging the Sync line, so Black box updates the data lines immediately after sensing a toggle (again it has a one value Queue inside it). The data now never changes except when the RC is busy, and it’ll be stable by the time the RC gets around to its next SERIN. If the black box micro choice is right, you simply tie Pulse to the interrupt line on the micro. The Interrupt Service Routine (ISR) can figure out the proper way to “clear” the interrupt so that the next transition triggers it again. If the ISR can’t read the interrupt’s hi/low status directly to properly “clear” the interrupt so it’s ready for the next transition, simply tie the signal to another input pin as well so it CAN read it.

Hopefully, this should guarantee valid data on EVERY loop.

Please let me know if you implement one of these before I do. I’m not at that point yet because I’ve been out with pretty serious Pneumonia so I’m about a 1.5 weeks behind in MY black box work.

FYI, I’m trying the Pulse Sync method first.

  • Keith
5

could explain a bit more about this ???

First off, you should use a high current bus driver between the micro and the RC, to insure that the line capacitance isn’t slowing the bit changes.

what is line capacitance? bit changes ?

6

*Originally posted by crazycliffy *
**could explain a bit more about this ???

what is line capacitance? bit changes ? **
Bit Change: One data I/O line = 1 Bit of data (aka bit, nybble, byte, etc…). Changing A Bit means shifting the value presented on a line from 0->1 or 1->0.

Line Capacitance: The wire between the black box and the RC is a “transmission line”. Think of it like a distributed resistance and capacitance, like an R/C circuit. When you change a bit, you are changing the voltage on it. It takes real time to discharge or charge that line to the new voltage value. Using a high current line driver chip on the output of your black box gives it more “omph” so any bit transitions flip quickly, and not linger in the “between” state.

Look at the StangSense schematic in the White Papers. The 74HC125 chips are the line drivers. The diodes going to the DB25 connector allow the 74HC125 chips to only SINK current (pull down), not SOURCE it (pull up).

BTW something else I forgot to mention: Without a line driver chip, the wire between the black CAN act as a “radio antenna”, picking up motor brush noise as data. Hard driving it with a line driver chip helps eliminate that. You should also consider using shielded wire between the black box and the RC, connecting the shield ONLY to the RC side’s ground connection.

  • Keith
7

*Originally posted by kmcclary *
**DV method:

Whenever the data is about to change, drop DV, toss in a few NOPs (No Operation opcodes) in the micro’s program to let the ringing stop, THEN change the value, wait a few NOPs again, then raise the DV line. Now you’re GUARANTEED that data will NEVER be changing while the DV line is high.**

Actually, this is only guaranteed to work if all the data in lines are latched at the same time. We’ve convinced ourselves that this is not the case. We did have a “data valid” flag last year to guard our data and it did not work. We found it is entirely possible to sense the data valid signal and still have corrupted data at the inputs.

**Handshake method:

Create a line pair between the black box and the RC, “request” and “valid”. Both are low initially. RC raises “request”. Black box puts data on and raises Valid. Once RC has it, it drops Request. Box drops Valid. This is ALWAYS guaranteed to work.**

Again, this only works if the data is clocked in at the same time. Now there’s just an added mechanism for the RC to request when data is sent.

**Pulse Sync method:

You can synchronize your updates to the loop time “heartbeat”. RC has a “Pulse Request” line toward the black box. The RC toggles this line every loop at the TOP of the loop (you’ll need a SECOND SEROUT statement to get that out. Use old values from the last loop for everything else). The Black Box has a one value Queue inside of it.

FYI, I’m trying the Pulse Sync method first.**

Our method this year will be similar to this as well. We’re testing it now to see if it meets our needs.

The reason the first two methods cannot be guaranteed to work when the data is not latched at the same time is this: suppose that some of the black box data lines are latched first. They’re still showing the old values. Now the black box data changes. Then the next set of inputs are latched, which contains the rest of the BB data lines which are now showing new values. OK, so now the RC has read bad data. Unfortunately, the BB data valid flag changes before the last set of inputs are latched (and the DV is connected to the last set of digital ins). Now the RC has invalid data but a valid flag. Oops. The only way to overcome that would be to delay after setting the data bits but before setting the valid flag. However, one needs to know how long to delay. If you don’t know this number and instead just guess, you can probably get it to be reliable. You can’t guarantee it though until you know precisely the time it takes the RC to latch all the digital inputs.

8

*Originally posted by Dave Flowerday *
**Actually, this is only guaranteed to work if all the data in lines are latched at the same time. We’ve convinced ourselves that this is not the case. We did have a “data valid” flag last year to guard our data and it did not work. We found it is entirely possible to sense the data valid signal and still have corrupted data at the inputs.

…]

The only way to overcome that would be to delay after setting the data bits but before setting the valid flag. However, one needs to know how long to delay. If you don’t know this number and instead just guess, you can probably get it to be reliable. You can’t guarantee it though until you know precisely the time it takes the RC to latch all the digital inputs. **
Yes, you DO have to delay at least one full RC I/O processor sample set time BOTH before, AND after data changes. That’s critical to insure the DV signal is good for the current data. Otherwise, you may see an “old” DV signal, or catch the “new” one too soon.

Good grief though, just how slow IS the RC’s I/O subsystem? When it did NOT work for you, how long WERE these delays?

  • Delay between DV drop & data change, AND
  • Delay between new presented data valid & DV rise

IOW, just how long DOES the RC’s I/O processor take to get around all of the I/O leads before “going for seconds”? Anyone have a glimmer of that figure?

Hmmm… That spec is important enough I may just call IFI Tech Support to find it.

  • Keith