Hi Folks,

OK that got your attention

A few days ago Dave (small.planes) posed the question 'how does the Spektrum AR6200 talk to the Remote Receiver'

[SPM9545] http://www.spektrumrc.com/Products/D...ProdID=SPM9545.

Well, as there are only 3 wires, how hard can it be

The answer - the interface is very simple!!

Dave bought an AR6200 with remote receiver and after a bit of probing with the scope and lashing in a MAX232 chip we now have the data on a PC

The communication is predominantly one way, SPM9545 to AR6200 (see binding below). It is a serial link similar to RS232 but with 3V logic levels running at 115K2 baud 1 start bit, one stop bit no parity. The idle state for the line is logic 1 (3V).

Packets are sent approx every 22ms and consist of 16 consecutive bytes.

Each Channel item is two bytes long with the least significant byte send first.

Packets for the DX7 and the DX6i are in a different channel order We suspect that as part of the bind the RX learns which sort of Tx it is bound to, otherwise the wrong servos would move!

Both formats use a sync word of 0x0301
then the DX7 has:

Aileron
Flaps
Gear
Elevator
Aux2
Throttle
Rudder

For example a centre stick packet from a DX7 is (HEX values):

0301 0601 1600 10AA 0A00 18AB 015F 0DFC

The DX6i has a different channel order:

Aileron
Flaps
Elevator
Rudder
Throttle
Gear
Aux2 - fixed value


Ranges for the values are (DX7)

Aileron:

left 0x5507 (21767)
centre 0x0206 (518)
right 0xAB04 (-21755)

Flaps:

up 0x5617 (22039)
centre 0x0016 (22)
down 0x9914 (-26347) Flaps seem to be a bit special in their range...

Gear:

up 0x5613 (22035)
centre -
down 0xAA10 (-21999)

Elevator:

up 0x560B (22027)
centre 0x000A (10)
down 0xAD08 (-21239)

Aux2:

up 0x571B (22299)
centre -
down 0xAB18 (-21735)

Throttle:

up 0x5503 (21763)
centre 0x0302 (770)
down 0xAA00 (-22015)

Rudder:

left 0x530F (21263)
centre 0xFF0D (-242)
right 0xAA0C (-22003)

Ranges for the values are (DX6i)

Aileron:

left 0x6007 (21263)
centre 0xFF05 (-250)
right 0xAE04 (-20978)

Flaps:

up 0x6517 (25879)
centre -
down 0x9914 (-26347)

Elevator:

up 0x540B (21515)
centre 0xFF09 (-246)
down 0xA708 (-22775)

Rudder:

left 0x4F0F (20239)
centre 0xFF0D (-242)
right 0xAB0C (-21747)

Throttle:

up 0x6103 (24835)
centre 0xFB01 (1278)
down 0xA600 (-23039)

Gear:

up 0x6513 (25875)
centre -
down 0x9910 (-26351)

Aux2: always 0018


These reading are from a new airplane model with no mixes on both TX's
The DX6i gives similar values except Aux 2 remains at 0x0018 since it is not (we presume) transmitted, or it is transmitted at a fixed value. (note: possible 'hack' on a DX6i for a 7th channel?)

The DX7 has 3 position Flaps, as opposed to the DX6i 2 position.

The values are nice simple 2s compliment numbers.

The remote receiver stops sending frames if the transmitter is turned off (and presumably if it loses the connection as well).


Binding
-------

There is some conjecture here but we suspect this is pretty close to what happens:

At power up the remote receiver [SPM9545] samples the data line, if it is high it waits for a bind request.

When in bind mode the main receiver performs the following actions:
It sets that data line to the remote receiver to high, waits 100ms and then send the following:

120µS Low
120µS High
120µS Low
120µS High
120µS Low
120µS High
120µS Low
then remains High

At some point the main receiver then redefines the data line as an input.

The remote receiver does not reply to this but enters into bind mode. Once it is bound it then transmits the data frames as described above.

Note the bind information is stored in the remote receiver, it is not sent from the main receiver to the remote receiver. The main receiver only requests that the remote receiver goes into bind mode - This is much simpler than it could have been!!!!

This is proven by first binding both receivers to one TX, and then rebinding just the Main receiver to a second TX.

With both TX's on both receivers have a solid LED, with just 1 only the correct receiver is lit. The suspicion that the main receiver knows which TX it is connected to is that the channel ordering changes in the packets on the link, The remote receiver appears to be 'dumb' and just send the channels in the order it receives them, leaving the main receiver to sort it out.


So what does this mean?

The SPM9545 remote receiver is about £20, $25, somewhat less than a AR6300

The SPM9545 remote receiver weights about 1 gram with no case. So a 1.3 gram DSM2 actuator drive system should be possible

More exotic solutions such a brushed twin steering system are possible. Or three actuators and a brushless ESC.......


It is possible that SPM9545 will work off 1 cell. Note it runs on 3V provided from the main receiver and has noregulator so an external regulator is needed for more than 1S. I suspect it will be safe to run at 5V from an ESC regulator but we havent tested this.

The main problem we see is the high data rate which may require a higher end processor.

suggestion: https://www.silabs.com/products/mcu/...s/default.aspx
something like the C8051F31x range has loads of pins in a tiny package

So over to you folks, who's volunteering for an open source solution
Best regards,

Andy and Dave.

If you look around the DIY electronics forum, you may find even more info about the DSM2 protocol. There is the post about the LP5DSM TX, the getting PPM from an AR7000 and the data protocol from the AR7000, AR9000 data port threads that come to mind straight away.

And if you really want open source, might be worth the time to use the CY6936 RF chip and couple it to an AVR and really go open source without infringing on the copyrights/patents.

this is GREAT news. I'm fiddling with the AR6300 and Koichis coildrivers. Need more time since i am starting up a indoors flying club and trying to get time to build some F3Ps to show at first meeting in a cpl of week. Then these ppl running around here calling me dad for some reason ?? well ill just ignore those.
An open src solutions for this would be great and the AR7000 i got i have no use for so i got the extra receiver
What did You have in mind for volunteers ??
/Ulf

I think the whole point of this is that you dont need to mess with the DSM2 Protocol, or any spread spectrum part of the RF side, its all done for you, so the advantages of the spektrum RF link are there.
The frame it spits out (in plain binary, no protocols at this level) is *EASILY* transformed into a (upto) 7 channel system. (I suspect, but dont have an 9303 or DSX9 to confirm, that you could have 9 channels from this RX, there *is* only 1 remote DSM2 RX afaik)
Just add a mirco with a standard UART at 115200 and read the chars off.
Change the firmware and actuators can become multi ESC channels, or servos or a mix and match.
Think of the remote RX as a kit that someone has provided which takes care of the rf link, and gives you a data frame, what you do with that is upto you.

Dave

Originally Posted by methuso

What did You have in mind for volunteers ??

Nothing much, just write the code and design the hardware

Seriously though this is really intended as a big hint to someone who has the time and inclination, it really would not be that hard. I really haven’t got the time and I'm resisting the inclination

I would also like to see an open code design solution to this.

Further to Dave’s comment you don’t even have to modify the SPM9545 (unless you want to remove the heavy connector!!)

I’ll cross reference in the DIY Electronic forum but I though this was of more interest to the indoor crowd.

Best regards,

Andy

This is cool stuff. Do check into my DSM2 transmitter project using the LP5DSM or similar tx board(same board a remote receiver uses more or less) The data looks pretty similar.

I think a simple receiver could be whipped up pretty quick using an Atmel AVR. Depending on what hardware is in a remote receiver less then 3 volts might be ok. The RF chip should be ok to somewhere around 2.6volts. Any Cypress CPUs though all need 3 volts.
I already have a receiver that works using a Maxstream xbee, it converts serial to PWM to drive servos and has failsafe integrated. A few minor changes and it should work with the Spektrum remote receiver. The nice thing about using the remote receiver is there should be no FCC issues. The various types of receivers may need to be sampled to see if the bind data is different. The data also needs to be looked at from a 2048 bit transmitter.

did a bit more probing this lunch.
Was thinking, as the 6100 and the main 6200 are the same PCB it makes no sense for them to have different firmware. So i checked, and lo and behold a 6100 puts the same bind signal out of the 3 pin header as the 6200

This isnt a lot of use, unless you have a 6100 but really need a 6200, in which case you can just add the remote RX, but its interesting anyway.

Steve, I dont understand the concern for a processor that runs at under 3V? If you are single Lipo cell then less than 3V is a bad thing anyway. Or have I misunderstood?

Dave

Andy and Dave,
Brilliant work. Kudos to you for doing this. I don't have the expertise to participate in this sort of thing. But, I'll be watching from the sidelines.

Gordon

I've been told that the AR6100 does indeed have different firmware and it will not work. Guess I need to go back and solder a connection onto one and try. It would be a lot easier to add a connector to an ar6100e than it would be to change to the right angle servo connectors on the ar6200.

Originally Posted by small.planes

Steve, I dont understand the concern for a processor that runs at under 3V? If you are single Lipo cell then less than 3V is a bad thing anyway. Or have I misunderstood?

Dave

The issue is that if you suddenly load the motor you may get a brief dip below 3 volts. Processors that have a hard cutoff of 3 volts instantly turn off/reboot during any kind of dip. To fly safely you need the electronics to work down to 2.5 to 2.7 volts unless you're quite careful to land early.

I have been thinking about this further and realized binding with just a satellite receiver will likely not be possible. During binding the main receiver sends a packet to the transmitter to ID the type/specs of the receiver. While the satellite also goes into binding mode I don't believe it transmits anything to the transmitter, only the main receiver does. If a DSM2 receiver doesn't send a packet during binding the DX7/x9303/12x etc will assume the receiver is DSM and not DSM2.

Of course it would be fine if we used a regular receiver to bind with and then unplugged it to use with out decoder module.

So whats the preferred hardware? I was thinking a tiny board with an Atmel AVR that had 3 actuator outputs and one PWM output. What kind of current does the average actuator require? An ESC can be included but brushless might be more fun anyway.

I would offer both a brushed and a brushless version of the board. Also an act and a servo version. That would make 4 different designs. Also would be nice if it had a buck/boost that could do 1, 2, or 3 cells and probably need to regulate for the servos at that point. Maybe only 1 and 2 cells

For the DM8/DM9 module users like myself, it should be easy enough to pull the TX ID out of the air and just load it into the receiver (maybe use an AVR Butterfly with RF6936 chip for this task). If you use a Butterfly, then you could also use it for programming failsafe features, and anything else that needed a cheap interface. Maybe you could trick a normal receiver into being a slave binding device for the Spektrum/JR transmitters. Maybe tap the data between the rf chip and the MCU on an AR6100 and pull the ID code into the Butterfly. That way you would still have model match, but you would lose the 2048 resolution (does anyone really need more than 1024 for an indoor model???).

Sure wish I was as good with developing this stuff as I am with the ideas of how to implement it.

Heh, I think you need to work on developing some more, then continue the dreaming.

I can't see anyone wanting to develop a bunch of different versions.

If I did one it would be as small, light and simple as possible. Binding would be handled by the stock main receiver, 3 acts, pwm or esc for the motor drive.

Ok, I hadnt considered the reboot issue... I tend to stop when my cells are about 3.2 - 3.4V, as with helis I find I cant concentrate any longer than about 6 to 8 mins...
Ill try and bind a remote RX on monday, when Im at work with the scope etc. I guess Ill force it into bind mode then unpower the main RX and see if I can bind it. I dont think having to plug into the main RX to bind would be that much of an issue, its not like you bind eveytime you fly, I have to partially disassemble my Gaui 200 to get the bind plug onto the RX for instance

Andy B is the man to ask about actuator drive, he has some code which is already open sourced for doing it. basically you drive a pair of outputs, pull one to ground and waggle the other one depending on the control throw, and for going the other way you pull the other one down and waggle the previously gnd one.

Dave

Hmm, scope and soldering iron out and Im (more) confused now...

The remote RX does indeed not work with the AR6100, the signals look ok, but there is a slight glitch, like the 6100 CPU not turning a pin round to input. could be that spektrum does have different firmware for the 2 RX's, tho that doenst make sense from a version control, bug fix etc POV

The remote RX is 5V proof (well 4.8V RX pack anyway). Good thing, as I forgot it was 3V til after Id connected it but it doesnt just run without being connected to the 6200...
Even with the 6200 bound to a different model (IE it hasnt initialised the link from the TX) the remote RX runs when the correct model is selected in the TX. Im not sure why it wont run 'standalone', I cant find any 'please go' commands coming from the Main RX, it 'just' starts sending frames when it links to the TX (led goes solid).

Dave

Originally Posted by TheSteve

So whats the preferred hardware? I was thinking a tiny board with an Atmel AVR that had 3 actuator outputs and one PWM output. What kind of current does the average actuator require? An ESC can be included but brushless might be more fun anyway.

Sounds good to me, I've ever used Atmel parts only PICs but to get to 115K2 with a PIC you really need an external xtal otherwise there would be little time left to run any code

I would consider a PWM signal for a small brushed motor maybe a 6A FET which would be OK for most pagers under stall. I would still include a servo style pulse to go to a brushless controller driven at the same time, small brushless is becomng very popular

Of course a simple starting point may be to emulate the 6300 in the AVR providing a slightly cheaper alternative to buying the 6300


Actuator coils are usually 50R or more say 30R worst case this gives 140mA so they are usually driven by a h-bridge or other driver.

Here are some popular ones:

A3901 0.4A RDS(ON) = 1.2R DFN package so hardest to solder but the smallest! One IC does one coil.

FDG6332C 0.6A RDS(ON) = 0.3R SC70-6 pretty small and still has legs! You need two per actuator.

NDC7001C 0.35A RDS(ON) = 7.5R SOT-6 easiest to solder, again you need two.


There are at least two schools of thought on driving actuators either standard PWM altering the mark space ration between full on and full off and Pulse Frequency Modulation, altering the frequency to the coil (I've never tried this but many people say its better!). In both cases one output is held steady as the other is driven. To drive the coil the other way you hold the other output steady while driving the other output.


Dave and I are totally puzzled as to why the remote receiver won't start up without the 6200 connected, We cannot see any exchange of data on the scope (other when binding) we've tried pulling the data line high and low via 20K and leaving it unconnected but not a squeak from the remote RX (It normally blips its LED at start up). I think this need to be cracked before going any further

Andy