Go to Post A Red Ryder 200-shot carbine Range model air rifle!!! - dlavery [more]
Home
Go Back   Chief Delphi > Technical > Programming
CD-Media   CD-Spy  
portal register members calendar search Today's Posts Mark Forums Read FAQ rules

 
Closed Thread
Thread Tools Rate Thread Display Modes
  #1   Spotlight this post!  
Unread 20-01-2003, 01:51
Micah Brodsky Micah Brodsky is offline
Registered User
#0824 (SWAT)
 
Join Date: Jan 2003
Location: Seattle
Posts: 5
Micah Brodsky is an unknown quantity at this point
Question Digital inputs, bandwith, errors?

[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!

--Micah Brodsky
  #2   Spotlight this post!  
Unread 20-01-2003, 08:18
Dave Flowerday Dave Flowerday is offline
Software Engineer
VRC #0111 (Wildstang)
Team Role: Engineer
 
Join Date: Feb 2002
Rookie Year: 1995
Location: North Barrington, IL
Posts: 1,366
Dave Flowerday has a reputation beyond reputeDave Flowerday has a reputation beyond reputeDave Flowerday has a reputation beyond reputeDave Flowerday has a reputation beyond reputeDave Flowerday has a reputation beyond reputeDave Flowerday has a reputation beyond reputeDave Flowerday has a reputation beyond reputeDave Flowerday has a reputation beyond reputeDave Flowerday has a reputation beyond reputeDave Flowerday has a reputation beyond reputeDave Flowerday has a reputation beyond repute
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   Spotlight this post!  
Unread 20-01-2003, 10:10
rust710's Avatar
rust710 rust710 is offline
Registered User
#0862 (Lightning Robotics)
 
Join Date: Dec 2002
Location: Canton, MI
Posts: 103
rust710 is an unknown quantity at this point
Send a message via AIM to rust710
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   Spotlight this post!  
Unread 20-01-2003, 13:37
kmcclary's Avatar
kmcclary kmcclary is offline
Founder 830/1015;Mentor 66/470/1502
FRC #0470 (Alpha Omega Robotics)
Team Role: Engineer
 
Join Date: Aug 2001
Rookie Year: 1994
Location: Ann Arbor, MI
Posts: 491
kmcclary has a reputation beyond reputekmcclary has a reputation beyond reputekmcclary has a reputation beyond reputekmcclary has a reputation beyond reputekmcclary has a reputation beyond reputekmcclary has a reputation beyond reputekmcclary has a reputation beyond reputekmcclary has a reputation beyond reputekmcclary has a reputation beyond reputekmcclary has a reputation beyond reputekmcclary has a reputation beyond repute
Data Valid

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
__________________
Keith McClary - Organizer/Mentor/Sponsor - Ann Arbor MI area FIRST teams
ACTI - Automation Computer Technologies, Inc. (Sponsoring FIRST teams since 2001!)
MI Robot Club (Trainer) / GO-Tech Maker's Club / RepRap-Michigan) / SEMI CNC Club
"Certifiably Insane": Started FIVE FRC teams & many robot clubs (so far)!
2002: 830 "Rat Pack" | 2003-5;14: 1015;1076 "Pi Hi Samurai" | 2005-6: 1549 "Washtenuts"/"Fire Traxx"
2005-(on): 1502 "Technical Difficulties" | 2006-(on): FIRST Volunteer!
2009-(on): 470 "Alpha Omega" | WAFL | Sponsor & "Floating Engineer" for MI Dist 13 (Washtenaw Cnty)
2011: 3638 "Tigertrons" | 2013-(on): 4395 "ViBots" | 2014-(on) 66 "Grizzlies"
"Home" Teams: 66, 470, 1076, 1502, 4395
Local FIRST alumni at or coming to Ann Arbor (UM/EMU/WCC/Cleary)?
...We Want YOU as a Mentor! Please email me for info!
Support CDF Reputation - If a posting helped, thank 'em with rep points!
"It must be FRC build season when your spouse and children become 'Action Items 8 & 9'..."

Last edited by kmcclary : 20-01-2003 at 13:41.
  #5   Spotlight this post!  
Unread 20-01-2003, 13:41
crazycliffy crazycliffy is offline
Registered User
#0846
 
Join Date: Jan 2003
Location: San Jose
Posts: 11
crazycliffy is an unknown quantity at this point
could explain a bit more about this ???


Quote:
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   Spotlight this post!  
Unread 20-01-2003, 13:55
kmcclary's Avatar
kmcclary kmcclary is offline
Founder 830/1015;Mentor 66/470/1502
FRC #0470 (Alpha Omega Robotics)
Team Role: Engineer
 
Join Date: Aug 2001
Rookie Year: 1994
Location: Ann Arbor, MI
Posts: 491
kmcclary has a reputation beyond reputekmcclary has a reputation beyond reputekmcclary has a reputation beyond reputekmcclary has a reputation beyond reputekmcclary has a reputation beyond reputekmcclary has a reputation beyond reputekmcclary has a reputation beyond reputekmcclary has a reputation beyond reputekmcclary has a reputation beyond reputekmcclary has a reputation beyond reputekmcclary has a reputation beyond repute
Quote:
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
__________________
Keith McClary - Organizer/Mentor/Sponsor - Ann Arbor MI area FIRST teams
ACTI - Automation Computer Technologies, Inc. (Sponsoring FIRST teams since 2001!)
MI Robot Club (Trainer) / GO-Tech Maker's Club / RepRap-Michigan) / SEMI CNC Club
"Certifiably Insane": Started FIVE FRC teams & many robot clubs (so far)!
2002: 830 "Rat Pack" | 2003-5;14: 1015;1076 "Pi Hi Samurai" | 2005-6: 1549 "Washtenuts"/"Fire Traxx"
2005-(on): 1502 "Technical Difficulties" | 2006-(on): FIRST Volunteer!
2009-(on): 470 "Alpha Omega" | WAFL | Sponsor & "Floating Engineer" for MI Dist 13 (Washtenaw Cnty)
2011: 3638 "Tigertrons" | 2013-(on): 4395 "ViBots" | 2014-(on) 66 "Grizzlies"
"Home" Teams: 66, 470, 1076, 1502, 4395
Local FIRST alumni at or coming to Ann Arbor (UM/EMU/WCC/Cleary)?
...We Want YOU as a Mentor! Please email me for info!
Support CDF Reputation - If a posting helped, thank 'em with rep points!
"It must be FRC build season when your spouse and children become 'Action Items 8 & 9'..."
  #7   Spotlight this post!  
Unread 20-01-2003, 15:07
Dave Flowerday Dave Flowerday is offline
Software Engineer
VRC #0111 (Wildstang)
Team Role: Engineer
 
Join Date: Feb 2002
Rookie Year: 1995
Location: North Barrington, IL
Posts: 1,366
Dave Flowerday has a reputation beyond reputeDave Flowerday has a reputation beyond reputeDave Flowerday has a reputation beyond reputeDave Flowerday has a reputation beyond reputeDave Flowerday has a reputation beyond reputeDave Flowerday has a reputation beyond reputeDave Flowerday has a reputation beyond reputeDave Flowerday has a reputation beyond reputeDave Flowerday has a reputation beyond reputeDave Flowerday has a reputation beyond reputeDave Flowerday has a reputation beyond repute
Re: Data Valid

Quote:
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.

Quote:
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.

Quote:
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   Spotlight this post!  
Unread 20-01-2003, 16:08
kmcclary's Avatar
kmcclary kmcclary is offline
Founder 830/1015;Mentor 66/470/1502
FRC #0470 (Alpha Omega Robotics)
Team Role: Engineer
 
Join Date: Aug 2001
Rookie Year: 1994
Location: Ann Arbor, MI
Posts: 491
kmcclary has a reputation beyond reputekmcclary has a reputation beyond reputekmcclary has a reputation beyond reputekmcclary has a reputation beyond reputekmcclary has a reputation beyond reputekmcclary has a reputation beyond reputekmcclary has a reputation beyond reputekmcclary has a reputation beyond reputekmcclary has a reputation beyond reputekmcclary has a reputation beyond reputekmcclary has a reputation beyond repute
Re: Re: Data Valid

Quote:
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
__________________
Keith McClary - Organizer/Mentor/Sponsor - Ann Arbor MI area FIRST teams
ACTI - Automation Computer Technologies, Inc. (Sponsoring FIRST teams since 2001!)
MI Robot Club (Trainer) / GO-Tech Maker's Club / RepRap-Michigan) / SEMI CNC Club
"Certifiably Insane": Started FIVE FRC teams & many robot clubs (so far)!
2002: 830 "Rat Pack" | 2003-5;14: 1015;1076 "Pi Hi Samurai" | 2005-6: 1549 "Washtenuts"/"Fire Traxx"
2005-(on): 1502 "Technical Difficulties" | 2006-(on): FIRST Volunteer!
2009-(on): 470 "Alpha Omega" | WAFL | Sponsor & "Floating Engineer" for MI Dist 13 (Washtenaw Cnty)
2011: 3638 "Tigertrons" | 2013-(on): 4395 "ViBots" | 2014-(on) 66 "Grizzlies"
"Home" Teams: 66, 470, 1076, 1502, 4395
Local FIRST alumni at or coming to Ann Arbor (UM/EMU/WCC/Cleary)?
...We Want YOU as a Mentor! Please email me for info!
Support CDF Reputation - If a posting helped, thank 'em with rep points!
"It must be FRC build season when your spouse and children become 'Action Items 8 & 9'..."
Closed Thread


Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
How to access other Digital inputs on OI? DougHogg Electrical 2 12-03-2003 13:57
Serial Port and Custom Circuit Ryan Meador Programming 40 06-02-2003 11:34
Specs full of errors??? Simon G Motors 1 20-01-2003 12:53
Analog vs Digital inputs? f22flyboy Programming 8 08-11-2002 22:18
making speed controller digital CharlieWilken Electrical 4 01-03-2002 20:15


All times are GMT -5. The time now is 19:02.

The Chief Delphi Forums are sponsored by Innovation First International, Inc.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi