Time for some technical content. I have started the receiver side program. This is where we read the AUX2 or Channel 7 pulse length to know which pin is being pressed. I wrote a simple program to display the value in a terminal window.
Here is a list of the key, the value in the program, the measured value.
prog measured
N 1100 1144uS
0 1150 1193uS
1 1200 1243uS
2 1250 1292uS
3 1300 1340uS
4 1350 1390uS
5 1400 1439uS
6 1450 1490uS
7 1500 1538uS
8 1550 1589uS
9 1600 1637uS
A 1650 1687uS
B 1700 1736uS
C 1750 1786uS
D 1800 1835uS
E 1850 1885uS
F 1900 1934uS
This is fine for doing some if-then statements to turn things on and off. Not sure why the discrepancy in values though. If the program is supposed to generate a 1100uS pulse, why is there a 40uS-ish discrepancy? I’m not doing any interupt or debug or even any terminal commands in the transmitter code. I measured with both a scope, and an Atom Pro doing a pulsin and serout-ing to a terminal with the same results.
Since your using a reciever and transmitter that is already FCC approved I dont see why you cant sell this as product. If you wanted to. You in no way modified the radio system therfore its still approved.
I did some testing and worked with Nathan… I know what the cause is. The overhead to get into the pauseus command after exiting the pusleout command is the culprit. The more complex the arguments for the command the longer it takes to get into the command. Takes less time to load a constant argument than a variable one, and it takes less time to load a variable than to calculate an expression. 8) Here is how I implemented the build PPM function.
So I broke some rules there. I need to do the math and send the results to variables, then do the above routine. There will be some overhead but once it’s calculated it should be constant in all the values, therefore making it possible to subtract it out. Yehaa! Mystery solved. 8)
The frÃ¥me rÃ¥te for receiving Ã¥ll chÃ¥nnels is Ã¥bout 23mS. This comes from the Ã¥irmod’s own microprocessor Ã¥nd is not Ã¥lterÃ¥ble. There mÃ¥y be some hÃ¥rdwÃ¥re Ã¥vÃ¥ilable in the future thÃ¥t will simplify this. We will see whÃ¥t cÃ¥n be done.
I hope that the read time can be short enough to add it to the main program. We could always go Zenta style and throw in another ATOM but I don’t have the shiny helmet to cover all the ATOM’s!
Ånd don’t tell me he tried to sell you the hårdwåre ås well!
I was thinking more along the lines of a little bitty PIC or Atmel board that can attach to the receiver to get the data. Some channels could be read directly by the Atom Pro, such as the joysticks (4 channels) if it’s more convenient, and some could be read from the co-processor via bidi ttl serial com. Atom says “what’s the status” the co-processor says “xxxx xxxx” etc. Most rover scenarios would not require it, but those pesky hexapods probably would.
LOL I have enough trouble just typing, let alone kicking around a foot pedal too.
I was thinking along this line as well and will try to help out. Alternativly I was thinking about trying out some of the Digi XBEE cards. I actually have purchased a couple different versions of these. My first attempt may be to use the version 1.x ones in transparent mode and on the remote, you simply send it out using serouts and on the robot simply receive the information with serin or hserin…
Before I left work several years ago with RSI problems in my hands, I was using one of these: kinesis-ergo.com/contoured.htm
It also had a foot pedal and the bright side of it was no one else wanted to use my computer!