Not sure whether this has already been covered (search was unsucceful) but what would be the best way to continuously log frames of pulse width modulated model RC commands without completely tying up a PICAXE? I was considering using a 08M that would be dedicated to measuring pulse width and feeding blocks of data form each frame to the serial scratchpad of a 28-X1. This second microcontroller would therefore be free to perform other tasks whilst receiving the RC data in the background. Has this approach got legs?
Logging RC command frames
- Thread starter MFB
- Start date
BeanieBots
Moderator
Not too sure exactly what you want to do.
The RC frame comes every 20mS, so if you want to act on every frame there is no alternative to testing each frame which does indeed tie up the PICAXE with only 20mS to do 'whatever' is required.
Having an 08M (or even an 08) reading in the pulses and then doing something simple such as putting a line high if the pulses are out of range is an easy option.
Maybe if you could be more specific about what you want to do we could give a more specific answer. It sounds like you want 'buffer' the RC signals. That would lead to questions about response times and what is/ is not acceptable. If you can 'wait' until your 28X1 gets around to processing the data, then why not simply only 'test' at that time.
RC signals are 'live' commnads. That is, this is what I want NOW. They are not a sequence of commands, missing something in the middle does not matter other than response time.
The RC frame comes every 20mS, so if you want to act on every frame there is no alternative to testing each frame which does indeed tie up the PICAXE with only 20mS to do 'whatever' is required.
Having an 08M (or even an 08) reading in the pulses and then doing something simple such as putting a line high if the pulses are out of range is an easy option.
Maybe if you could be more specific about what you want to do we could give a more specific answer. It sounds like you want 'buffer' the RC signals. That would lead to questions about response times and what is/ is not acceptable. If you can 'wait' until your 28X1 gets around to processing the data, then why not simply only 'test' at that time.
RC signals are 'live' commnads. That is, this is what I want NOW. They are not a sequence of commands, missing something in the middle does not matter other than response time.
BeanieBots...I basically want to measure each pulse of the serial frames from the RC receiver before their decoded for individual servos, in order to log received commands.
The monitoring circuitry would T-off the output from the receiver and should not effect normal decoder/servo operation. It might be possible to do this with a single X2 and still have time to perform other tasks between frames (but how to detect the end of frame sync pulse?).
The monitoring circuitry would T-off the output from the receiver and should not effect normal decoder/servo operation. It might be possible to do this with a single X2 and still have time to perform other tasks between frames (but how to detect the end of frame sync pulse?).
BeanieBots
Moderator
Are you talking about the signal going to the servo (going up the tree wire lead) or the uncoded pulse stream between the radio reciever and the channel decoder?
BeanieBots
Moderator
Decoding that signal would be a full-time job for any PICAXE. However, reading the decoded signal is a simple on demand pulsin.
Still not fully understanding what your problem is.
Why do you want to "log" this data?
Maybe if you could describe your target function?
There was a thread (several years ago now) which included a document giving all the different encoding methods. PPM7, PPM9, PCM being the most common. With luck, somebody might recall the post (eclectic?) or somebody might know the document (Wrenow?).
Worth having a browse because this has been doen before. I've actually done it myself but only to prove it could be done and never kept the notes.
Still not fully understanding what your problem is.
Why do you want to "log" this data?
Maybe if you could describe your target function?
There was a thread (several years ago now) which included a document giving all the different encoding methods. PPM7, PPM9, PCM being the most common. With luck, somebody might recall the post (eclectic?) or somebody might know the document (Wrenow?).
Worth having a browse because this has been doen before. I've actually done it myself but only to prove it could be done and never kept the notes.
You rang Mr BB?
Here's a starter:
http://www.picaxeforum.co.uk/showthread.php?t=6483&highlight=encode*+ppm*
e
Here's a starter:
http://www.picaxeforum.co.uk/showthread.php?t=6483&highlight=encode*+ppm*
e
BeanieBots
Moderator
New I could rely on you to find it eclectic
Many thanks for useful comments and links. I was sure this topic had been visited before but my search drew a blank. An X2 running at 40MHz might be able to measure and store the duration of pulses arriving serially but agree that it would be easer to handle the outputs from the decoder, at the expense of using one PICAXE input per channel. This approach would also eliminate the need to detect frame synchronization. So that’s the way I'll go.
BeanieBots
Moderator
Still not clear what your REAL issue is.
If you read the pulses in the right order, you can do all eight in one 20mS frame. The pulse itself provides the framing.
Once 'stored', then what?
What are you actually trying to do?
If you read the pulses in the right order, you can do all eight in one 20mS frame. The pulse itself provides the framing.
Once 'stored', then what?
What are you actually trying to do?
BeanieBots, I’m pleased to say there is no longer an issue. The application requires that all received servo commands are stored for replay (to ‘teaching’ a sequence of actions). My initial approach, of trying to use only one PICAXE pulsin input to serially measure and store the duration of each channel pulse, would have been more complicated than dedicating a separate input to each channel of the decoder output. An advantage being that the decoder has already synchronized on the inter-frame gap and allocated the pulse to the correct servo channel/PICAXE input. The main disadvantage of this parallel approach is that one input must be used per channel but this should not be a limitation for most low cost RC systems.
BeanieBots
Moderator
OK, makes sense now.
Indeed, one input per channel is required but if you read them in sequence, all can be read (and stored) in one frame period.
Only store if old value is different to new value. Should be able to get a very long sequence as long as not all channels change continuously.
EDIT:
Just a thought, have you considered logging even further up the chain?
Namely, log (using readADC) the 'stick' positions.
Many RC flight simulators have this as a built in function so that you can play back your simulated flight.
Indeed, one input per channel is required but if you read them in sequence, all can be read (and stored) in one frame period.
Only store if old value is different to new value. Should be able to get a very long sequence as long as not all channels change continuously.
EDIT:
Just a thought, have you considered logging even further up the chain?
Namely, log (using readADC) the 'stick' positions.
Many RC flight simulators have this as a built in function so that you can play back your simulated flight.
Last edited:
Just so you are aware, you do know there is a servo recorder you might want to know about. http://servocity.com/html/servo_recorder_playback_contro.html
Also, their are some similar but more capable models available for the special effects guys, http://www.bpesolutions.com/product.html, and I forget, sorry, but several others out there.
The servo city one, you just dial in what you want the servos to do and they remember the sequence - no radio necessary.
Cheers,
Wreno
Also, their are some similar but more capable models available for the special effects guys, http://www.bpesolutions.com/product.html, and I forget, sorry, but several others out there.
The servo city one, you just dial in what you want the servos to do and they remember the sequence - no radio necessary.
Cheers,
Wreno
Ok, I guess I misunderstood that you were trying to record those so that you would be able to play back a sequence of actions.
If you ore recording the pulses for some other reason, keep in mind that the 20ms "frame" can be pretty darned full. If all the pulses are at their full extension (say every stick over hard) at the same time, then you are going to get 18ms of pulses (for a 9 channel radio) in a 20ms frame. Doesn't leave a lot of time for the write cycle before the next frame starts. The parallax SX chips can handle a lot of channels (I have seen 6), and the X2's probably. I have never done more than 3-4 channels at a time with an O8M, and I do not try to output or save the information, just pass one modified pulse down the RC pipe.
My point being that whatever you logging/reporting functions, they will need to take place in a pretty tight window. I will be fascinated to see how you get on with it.
Good luck,
Wreno
If you ore recording the pulses for some other reason, keep in mind that the 20ms "frame" can be pretty darned full. If all the pulses are at their full extension (say every stick over hard) at the same time, then you are going to get 18ms of pulses (for a 9 channel radio) in a 20ms frame. Doesn't leave a lot of time for the write cycle before the next frame starts. The parallax SX chips can handle a lot of channels (I have seen 6), and the X2's probably. I have never done more than 3-4 channels at a time with an O8M, and I do not try to output or save the information, just pass one modified pulse down the RC pipe.
My point being that whatever you logging/reporting functions, they will need to take place in a pretty tight window. I will be fascinated to see how you get on with it.
Good luck,
Wreno