Interpreting Serial Output

Y

Yessir

Member
Hi all, its been a few years since I last posted on the forum - still working with Picaxe projects but slowing down a bit these days.

I have run into a problem trying to interpret serial data. I have an RC crane model which is controlled with an RC transmitter / receiver. I want to replace the transmitter / receiver with a Picaxe to allow the crane to work autonomously. The crane is connected to the RC receiver using a serial connection which allows multiple functions (raise/lower, left/right, in/out) to be sent over a standard 3 wire servo cable. I can't find any information on the serial protocol, so I have connected the receiver to an oscilloscope and captured the serial output which I have saved into the attached spreadsheet so that I can chart it to help me understand it. Each data bit seem to be about 25us - 26us in length which equates to a baud of about 38400. The problem is interpreting the data to see if I can generate a similar serial output using a Picaxe. The data doesn't appear to conform to 8n1 - it just seems to be a stream of 40 bits. This pattern repeats every 20ms. The good news is I can see data bits changing as each crane function is selected.

Any assistance interpreting the data and determining if I can generate a similar output with a Picaxe would be appreciated.
 

Attachments

Hi,

It might be easier if you could present the data in a different form, such as from the open-source Sigrok/Pulseview application (Windows), because I think we really will need to see multiple "messages" to demonstrate how and which bits are actually changing. Some related posts on the forum HERE and HERE mention its use (within much longer threads) and HERE is an example of its presentation.

The data format appears to be approximately a constant data-bit period of about 100us (i.e. 10 kHz) with a duty cycle (ratio of High to Low levels) of about 1:3 or 3:1 . That is much faster than most simple Infra Red or Radio (e.g. 433 MHz) Remote Control protocols which use typically one kbit/second. These protocols also generally use either a constant-width "Pulse" with a variable width "Gap" (or vice versa) that is generally easier to decode (for example with PICaxe's PULSIN instruction) or encode (e.g. with PULSOUT).

Therefore, I'm not at all confident that your protocol is manageable with a PICaxe (even at 32 MHz or 64 MHz for an M2/X2), at least without some degree of "hardware assistance". However, there is quite a lot of "free" hardware in the PICaxe chips, which might be of assistance if you don't mind "getting your hands dirty" with the PEEK/POKESFR commands. ;)

Cheers, Alan.
 
There seem to be relatively few crane 'commands' involved, so you could predefine them (using macros) - maybe don't need to actually understand the protocol...

I can't imagine you would be able to dynamically generate the bitstream anyway, given the very short time between pulses.

I took the static route, when reproducing the PKES signal from my Hyundai Tucson. I defined four macros: ShortON,ShortOFF,LongON & LongOFF and used them to define the datastream to be transmitted.

Finding the Picaxe statements to place in each macro was a matter of trial-and-error, using the 'scope.
 
It could well be PPM or SBUS, what make of radio gear is it ?.
If it's PPM, then PWM to PPM encoders are readily available and cheap as chips.
 
Thanks for the feedback. The radio gear is Hengguan Technology - Trasped 16C. It appears to have 7 x conventional RC channels & 1 x digital channel which controls the crane.
I have attached a PDF with screen grabs from oscilloscope. The first 3 x images are to illustrate the waveform with cursers placed to measure the duration of bit and the gap. The second 3 x images are to illustrate what changes when a function is selected. The top image is no function, the next two are two different functions selected. I have circled the bit which seems to get set with each function.
I am wondering if I can bit-bang an output using PULSOUT and PAUSEUS but I don't know if I can get commands to run fast enough - particularly on parts of the data stream where one bit immediately follows another?
 

Attachments

Hi,

With the PCB/DP Scope it's possible to display "Data Eyes" directly, using its "Persistence" mode, that can show which parts of the waveform are changing. As an example (stolen from a previous thread :) ), here's a SCREENSHOT that I created for post #1 of Another Thread which shows a "multiple exposure" of two (changing) "concatonated" ASCII characters (consecutive, touching at the vertical centre-line).

Certainly the easiest (and probably the only) method to generate that data stream is to use direct "linear" code (i.e. no "Jump" commands such as GOTO, IF, FOR, etc., and certainly no GOSUBs) as described by Phil in #3 above, but IMHO the timing is still very marginal. It might just be possible with an 08M2 (which is a little faster than other M2s because it has simpler hardware to support) at 32 MHz, or an X2 chip at 64 MHz (that I've not measured, but is unlikely to be as much as twice as fast, because it needs longer "tokens" to support the more complex hardware).

Generally, the fastest instructions are the HIGH and LOW , which I've measured can execute in about 37us (microseconds) on an 08M2 at 32 MHz. That's slower than you need, but perhaps the decoder will tolerate a 1:2 duty cycle instead of 1:3 , and a slightly lower bit rate. So it might be worth trying to see if the receiver will tolerate messages based on HIGH : LOW : LOW* (e.g. for Data 0 bits) and HIGH : HIGH* : LOW (e.g. for data 1). You can use CALIBFREQ (with values from 224 through 255 , 0 to 31) to shift the clock frequency by up to +/-3% to check if the timing/frequency is marginal.

The "overhead" (processing time) of the PULSOUT command is about 80 us (with an 08M2 at 32 MHz), so a sequence of PULSOUT 16 might deliver an acceptable string of "0" or "1" bits (depending whether it starts from a Low or High level) , but I can't see how any changes between the "0" and "1" bits could be achieved within the required timing. It's interesting that PULSOUT and PAUSEUS have almost identical execution times (for the same parameter) so may use common code.

Similarly, a PWM output could be set up to generate a 1:4 duty pulse train at 10 kHz, with a program of the form PAUSEUS nn : PWMOUT... {4:1 duty cycle} changing the duty cycles "on the fly", but it would need a lot of trial and error to setup the delays. Note that PWMDUTY.... is a very slow instruction (executing in around 1ms at 32 MHz), but the hardware associated with PWMOUT does appear to maintain complete cycles, so a POKESFR .... (to one of the PWM registers) might be preferable. However, the pins and hardware used by the PWM are not fully documented for the PICaxe, and the base PIC data sheets are complex (which I'm only just beginning to understand for the PWM module).

* ADDED : A PAUSE 0 might be slightly faster than the repeated HIGH or LOW instructions, which could get closer to the desired 100us cycle time (or perhaps tweak it with a mixture of both), but note that a PAUSEUS 0 takes significantly longer! For an M2, both of these "bit" code formats compile to (an average of) about 7.9 bytes. However, for an X2, the PAUSE 0 version compiles to about 9.3 bytes, and the HIGH/LOW version to 10.1 bytes, indicating the longer tokens (and hence slower execution time) needed for the increased pin-count and program address range.

Cheers, Alan.
 
Last edited:
Yessir said:
This pattern repeats every 20ms.
Click to expand...
Does the crane use R/C servos?

If it does then an alternative approach would be to drive the three servo's directly. This would be much easier for a PICAXE to do then trying to generate the high speed serial that the crane uses.
 
Last edited:
Thanks for all the information - its been some really useful reading.

I started writing some test code using Pulsout and have stumbled across a solution which seems to work. It would appear that the timing of the 'gap' between pulses is not critical provided that a stream of 40 pulses is received by the crane. I have therefore defined the duration of a long pulse and short pulse which match the observed receiver pulses and then output a series of 40 Pulsout commands. The only timing issue I have come across is the output needs to be repeated about every 20ms to prevent stop/start stuttering of the crane. By choosing variables for some of the pulses I can then write some other code to control the crane operation. All running on Picaxe 18M2 @16MHz. Copy of code below for anybody who is interested.

Code: 
    setfreq m16    
    
'    Define Constants - used to adjust pulse lengths
    Symbol Short = 10                        ' approx 25us pause @ M16
    Symbol Long = 28                        ' approx 70us pause @ M16
    
'    Define Variables (variables numbers chosen to match output pulse number)
    Symbol Main_Up = b1
    Symbol Main_Down = b2
    Symbol Lower_Up = b3
    Symbol Lower_Down = b4    
    Symbol Arm_Out = b5
    Symbol Arm_In = b6
    Symbol Winch_In = b7
    Symbol Winch_Out = b8
    Symbol Slew_Right = b17
    Symbol Slew_Left = b18

'    Set Initial Crane Values (All functions off - short pulse)
    Main_Up = Short
    Main_Down = Short
    Lower_Up = Short
    Lower_Down = Short
    Arm_Out = Short
    Arm_In = Short
    Winch_In = Short
    Winch_Out = Short    
    Slew_Right = Short
    Slew_Left = Short
    Low B.0                                ' Set crane output pin low on start up

main:
    
    Gosub Crane_Output                        ' Call subroutine to output crane pulses
    
    ' Insert other code in here to change variables from short to long etc.

    Pause 15                                ' adjust to achieve approx 20ms separation between data repeats
    Goto Main
    
    Return

Crane_Output:

'    Pulse 1
    pulsout B.0, Main_Up 
'    Pulse 2
    pulsout B.0, Main_Down 
'    Pulse 3
    pulsout B.0, Lower_Up 
'    Pulse 4
    pulsout B.0, Lower_Down 
'    Pulse 5
    pulsout B.0, Arm_Out 
'    Pulse 6
    pulsout B.0, Arm_In 
'    Pulse 7
    pulsout B.0, Winch_In 
'    Pulse 8
    pulsout B.0, Winch_Out 
'    Pulse 9
    pulsout B.0, Short 
'    Pulse 10
    pulsout B.0, Short 
'    Pulse 11
    pulsout B.0, Short 
'    Pulse 12
    pulsout B.0, Short 
'    Pulse 13
    pulsout B.0, Short 
'    Pulse 14
    pulsout B.0, Short 
'    Pulse 15
    pulsout B.0, Short 
'    Pulse 16
    pulsout B.0, Short 
'    Pulse 17
    pulsout B.0, Slew_Right 
'    Pulse 18
    pulsout B.0, Slew_Left 
'    Pulse 19
    pulsout B.0, Long 
'    Pulse 20
    pulsout B.0, Short 
'    Pulse 21
    pulsout B.0, Short 
'    Pulse 22
    pulsout B.0, Short 
'    Pulse 23
    pulsout B.0, Short 
'    Pulse 24
    pulsout B.0, Short 
'    Pulse 25
    pulsout B.0, Short 
'    Pulse 26
    pulsout B.0, Short 
'    Pulse 27
    pulsout B.0, Long 
'    Pulse 28
    pulsout B.0, Short 
'    Pulse 29
    pulsout B.0, Short 
'    Pulse 30
    pulsout B.0, Short 
'    Pulse 31
    pulsout B.0, Short 
'    Pulse 32
    pulsout B.0, Short 
'    Pulse 33
    pulsout B.0, Long 
'    Pulse 34
    pulsout B.0, Short 
'    Pulse 35
    pulsout B.0, Short 
'    Pulse 36
    pulsout B.0, Short 
'    Pulse 37
    pulsout B.0, Short 
'    Pulse 38
    pulsout B.0, Short 
'    Pulse 39
    pulsout B.0, Short 
'    Pulse 40
    pulsout B.0, Short 
    
    Return
 
neiltechspec said:
It seems as though times have changed & they are not so readily available or cheap any more
Click to expand...
neiltechspech & Yessir,

I handn't heard of these before so I checked it out after neiltechspech's original post and found that they are several different versions available.

Yessis is in the UK and a search for "PPM encoders" on ebay.co.uk came up with this version that converts between all the three options PWM, PPM & SBUS:

I chose this example to post as an example because the ebay item has this description:
Wiring instructions:
When any one or more channels of the 1-8 channel input PWM signals, the corresponding PPM channel outputs the PPM signal, and the SBUS channel outputs the SBUS signal.
When the PPM channel inputs the PPM signal, it corresponds to the 1-8 channel output PWM signal, and the SBUS channel outputs the SBUS signal.
When the SBUS channel inputs the SBUS signal, it corresponds to the 1-8 channel output PWM signal, and the PPM channel outputs the PPM signal.

The standard disclaimer applies. I have never used one of these modules so I can't vouch for how well they work and Yessir will have to decide whether to buy one to try it out.
 
You must log in or register to reply here.
Back
Top