Thread Tools
Mar 07, 2016, 03:31 PM
Pascal
hpnuts's Avatar
Quote:
Originally Posted by rbecq
Does the fact that the module has to decode serial signal introduce any latency, and if so, roughly how much would it be? In other words, could any guru here describe how does the serial mode work?

PPM frame is at least ~20ms, so that's settled, but I'm interested in the serial mode, and particularly compared with soldering the RF modules directly to the main board like in Deviation. Thanks!
Serial mode consists of a frame of 16 channels coded on 11 bits (0..2047) sent every 11ms to the multi module by the TX er9x/ersky9x/OpenTX.
Then depending on the selected protocol these servos data are sent with another timingwhich highly varies from one protocol to the other.
Latest blog entry: Samson RC Tugboat
Sign up now
to remove ads between posts
Mar 07, 2016, 03:44 PM
Registered User
Quote:
Originally Posted by hpnuts
Serial mode consists of a frame of 16 channels coded on 11 bits (0..2047) sent every 11ms to the multi module by the TX er9x/ersky9x/OpenTX.
Then depending on the selected protocol these servos data are sent with another timingwhich highly varies from one protocol to the other.
Is it a well-known serial protocol, or something invented for multiprotocol module? What is the limiting factor that make the frame 11ms, instead of say, 1.1ms, in which case the latency can be reduced by 10x?
Mar 07, 2016, 04:04 PM
Pascal
hpnuts's Avatar
Quote:
Originally Posted by rbecq
Is it a well-known serial protocol, or something invented for multiprotocol module? What is the limiting factor that make the frame 11ms, instead of say, 1.1ms, in which case the latency can be reduced by 10x?
The serial protocol used is SBUS @ 100kbps 8e2 25 bytes. Only a couple of bytes in the frame are different and specific to multi. Transmission of a full frame is already taking 3ms at that given speed.
2 things:
- I'm not sure how fast the TX firmware is really generating all outputs based on all the mixers and all kind of things you can add on the signals. And I'm not sure how faster we could go without impacting the calculations time as well since we are using fast bit banging which is not leaving much time to do other things.
- RF protocols do have their own timing anyway. For example DSM2/X is 22ms<7ch or 11ms>7ch, what's the point of going faster for this type of protocol?

Pascal
Last edited by hpnuts; Mar 07, 2016 at 04:53 PM.
Mar 07, 2016, 04:55 PM
Registered User
pascal,
so i hooked up the CYRF6936 according to the pinout you gave me a link to. i still am unable to bind to my mSRX. the heli stays in bind mode. when i push the bind button as i boot up, it only blinks rapidly for about 3 seconds. is the bind window too short? is there a way of lengthing the binding time? when i install my DM9, the binding process takes some time.
my mSRX can bind in either DSM2 or DSMX. i have the baseline multiprotocol loaded. i've got the rotary dip switch set to channel 6. i also tested channel 4 and channel 9 and they still work fine. how can i tell if i've got some screwed up wiring or if i've got a bad rf board or if the bind window is just too short?
thanks.
-beanie
Mar 07, 2016, 05:06 PM
Registered User
Thanks for the answers! I'm learning quite a bit here, but here comes more questions

Quote:
Originally Posted by hpnuts
I'm not sure how faster we could go without impacting the calculations time as well since we are using fast bit banging which is not leaving much time to do other things.
Give this, is it fair to say that even if the protocol is implemented on the main MCU, it can't afford monitoring TX stick movement all the time, since it has to have some cycles to compute mixing, etc, so there is also some gap, just might not be as long as 11ms?

Quote:
Originally Posted by hpnuts
RF protocols do have their own timing anyway. For example DSM2/X is 22ms<7ch or 11ms>7ch, what's the point of going faster for this type of protocol?
If I understand correctly, the latency is added on top of the protocol itself, even though DSM2/X has 22ms latency, adding another 11ms just make it even longer. But I see the practical constraints here.
Mar 07, 2016, 07:09 PM
Registered User
I added a custom option to specify type and subtype without restrictions. Is that something in the direction you would like see being support @hpnuts?

I will add autobind and low power later.
Mar 07, 2016, 09:40 PM
Registered User
pascal,
aside from my 2 questions above, can you also verify that CYRF CSN on the schematic correlates with CS/SS in the picture you gave me the link to for the Devo module?
-beanie
Mar 07, 2016, 11:08 PM
Registered User
here is some more odd behavior with my DSM2 setting. i was able to get it to work after tying the 3 unlabeled pins together. but, there are a couple issues:
1) it takes a very very long time to bind
2) after it binds, it is fine until i power down the receiver. once i power down the receiver, then power it back up again, no binding occurs. the only way to get a bind again is to put the receiver back into bind mode.
3) i can't bind with my mSRX, but i can bind to orange DSM2 receiver, but with the caveat mentioned above

i don't know if this matters, but i'm using 22.5ms and 400 with positive polarity (i read 11ms somewhere, but the lowest i can set it to is 13.5ms)
any ideas/suggestions?
thanks
-beanie
Mar 08, 2016, 03:17 AM
Pascal
hpnuts's Avatar
@beanie
Quote:
i was able to get it to work after tying the 3 unlabeled pins together
I don't know what's behind the 3 pins that you've tight together. If you follow the schematic you will see that one of the 3 pins (middle one) has to be connected to GND and the 2 others left unconnected.
Quote:
after it binds, it is fine until i power down the receiver. once i power down the receiver, then power it back up again, no binding occurs. the only way to get a bind again is to put the receiver back into bind mode.
This is weird since the ID used is directly given by the cyrf manufacturer ID. And this number is not supposed to change at all... Are you sure of all your connections? (Specially a bad contact on MISO). It might be related to the point above as well...
Quote:
it takes a very very long time to bind
Can you explain what you mean by long time?
Bind time, as you said, is only 3 seconds.
After that normal packets are being sent but there is a particularity in the code at that stage. It does not send the "real" servo position unless you move elevator or aileron. This has to do something around setting fail safe.
Quote:
is the bind window too short? is there a way of lengthing the binding time?
You can increase the bind time by modifying in the file DSM2_cyrf6936.ino this line #define BIND_COUNT1 600. 600 gives 3sec => 600/2*0.01=3. So if you put 1200 instead, the bind window is 6s.
Quote:
i don't know if this matters, but i'm using 22.5ms and 400 with positive polarity (i read 11ms somewhere, but the lowest i can set it to is 13.5ms)
This has nothing to do with your issue... You can always lower your 22.5ms PPM settings to get a faster refresh of your servo if you wish but again it's unrelated to your issue. Don't mix protocol timing (11ms for DSM) and PPM timing these are 2 different things.

- Pascal
Latest blog entry: Samson RC Tugboat
Mar 08, 2016, 04:22 AM
Pascal
hpnuts's Avatar
Quote:
Originally Posted by rbecq
If I understand correctly, the latency is added on top of the protocol itself, even though DSM2/X has 22ms latency, adding another 11ms just make it even longer.
It's not that easy and does not adds up like you say. Since within your 22ms multi has received at least 1 servo update. So the 22ms stays 22ms which is the protocol refresh rate.
- Pascal
Latest blog entry: Samson RC Tugboat
Mar 08, 2016, 04:27 AM
Pascal
hpnuts's Avatar
Quote:
Originally Posted by plaisthos
I added a custom option to specify type and subtype without restrictions. Is that something in the direction you would like see being support @hpnuts?

I will add autobind and low power later.
It looks good :-)
Have you coded this option something like after the last known protocol it displays custom and adds 2 numerical fields to select type and subtype?
- Pascal
Latest blog entry: Samson RC Tugboat
Mar 08, 2016, 04:46 AM
Registered User
Quote:
Originally Posted by hpnuts
It looks good :-)
Have you coded this option something like after the last known protocol it displays custom and adds 2 numerical fields to select type and subtype?
- Pascal
Yes. That is exactly what I did.
Mar 08, 2016, 10:07 AM
Registered User
@hpnuts,
thanks again for your advice. i’ll triple check my connections again tonight after work.

the 3 pins i was referring to are the 3 in the middle of the bottom row of the top part of the picture that you sent in this link: http://www.hacksmods.com/wp-content/...tion_guide.jpg i see that the ground is the middle of the top row. the schematic accounts for 8 of the 10 pins on the module.

by “long time to bind”, i mean, about 50-55 seconds. i am moving the aileron stick constantly to see when a successful bind occurs. also, the bind only is successful about once in 6-7 attempts. once the bind is successful, then as long as power to the receiver is not interrupted, i can maintain a bind. i can power the transmitter on and off and still maintain bind. but as soon as i take away power to the receiver, i have to re-attempt the binding procedure.

i just wanted to give a step by step to see if you see anything i’m doing wrong:
1) i apply power to the receiver (Rx) with the bind plug in… led on the Rx blinks rapidly
2) i apply power to the transmitter (Tx) while holding down the bind button… the led on the Tx blinks rapidly for about 2-3 seconds
3) as the Tx led starts to blink rapidly, the Rx led turns off
4) then the Tx led goes solid while the Rx led remains off
5) after about 50-55 seconds, i can control the ailerons. the led on the Tx remains on while the Rx led remains off. the bind is only successful once ever 6-7 times. after 1.5minutes, if is still have no control, i power everything off and repeat all the steps to try to get a bind. i have waited up to 5 minutes without any difference. it looks like the bind will occur at about 50 seconds if it is going to happen at all.

is there a way to see if my Devo/CYRF6936 board is bad? (i don’t have an oscilloscope or would even know how to use 1 even if i did). but i guess that if the board was bad, i wouldn’t ever have any successful bind.

thanks again for all your time and help. it is greatly appreciated.
-beanie
Mar 08, 2016, 10:27 AM
Registered User
midelic's Avatar
Thread OP
This 3 pins at the bottom should not be all connected togheter,only the 2 pins up/down in the middle(GND),I think they are connected on the board.

Did you check also with orange RX?
I have tested this multimodule before with 3 rx DSM2 .
1 The lemon featherlight DSm2
2.Orange DSM R615.
3.Parzone Sukhoy rx.
All working just fine.

If you can bind the chances are that your devo module is good.

I red somewhere that it will be a problem with MCPX.... but the orange should work just fine.
Do me a favor look back in this thread search for an older version of multiprotocol, flash your module and try again.
I'm at work and going home in 3 weeks , and have no possibility to try and test the last multiprotocol code.
Mar 08, 2016, 10:54 AM
Pascal
hpnuts's Avatar
Quote:
Originally Posted by beanie
the 3 pins i was referring to are the 3 in the middle of the bottom row of the top part of the picture that you sent in this link: http://www.hacksmods.com/wp-content/...tion_guide.jpg i see that the ground is the middle of the top row. the schematic accounts for 8 of the 10 pins on the module.
Me too... The schematic is giving you 8 pins to connect, if you only look at the pins in the picture I shared you only find 7 highlighted. So I'm saying the missing pin is the one is the middle of low row. On the picture the number would be 8 which corresponds to number 5 on the schematic. I know it's not the best but you need to remap the pin numbers between picture and schematic.
Edit: in fact if you look here you can see that on the PCB the middle pin is already grounded on the PCB. You can confirm on yours that it's the same. I'm really suggesting to double-triple check your cabling.

Quote:
Originally Posted by beanie
by “long time to bind”, i mean, about 50-55 seconds. i am moving the aileron stick constantly to see when a successful bind occurs. also, the bind only is successful about once in 6-7 attempts. once the bind is successful, then as long as power to the receiver is not interrupted, i can maintain a bind. i can power the transmitter on and off and still maintain bind. but as soon as i take away power to the receiver, i have to re-attempt the binding procedure.
Ok so the ID is remaining constant when you turn on/off the TX, I was under impression it was not the case. I have no idea why the RX is not keeping the settings...

Quote:
Originally Posted by beanie
i just wanted to give a step by step to see if you see anything i’m doing wrong:
1) i apply power to the receiver (Rx) with the bind plug in… led on the Rx blinks rapidly
2) i apply power to the transmitter (Tx) while holding down the bind button… the led on the Tx blinks rapidly for about 2-3 seconds
3) as the Tx led starts to blink rapidly, the Rx led turns off
4) then the Tx led goes solid while the Rx led remains off
5) after about 50-55 seconds, i can control the ailerons. the led on the Tx remains on while the Rx led remains off. the bind is only successful once ever 6-7 times. after 1.5minutes, if is still have no control, i power everything off and repeat all the steps to try to get a bind. i have waited up to 5 minutes without any difference. it looks like the bind will occur at about 50 seconds if it is going to happen at all.
That's really strange. Since I don't have a cyrf module I have no idea of the bind process so if other peopele could chime in...

Quote:
Originally Posted by beanie
is there a way to see if my Devo/CYRF6936 board is bad? (i don’t have an oscilloscope or would even know how to use 1 even if i did). but i guess that if the board was bad, i wouldn’t ever have any successful bind
It looks like it does what it should. The fact that you can turn off/on the TX without loosing the link seems a good thing to me...

I have a new version of DSM2/X which I've never pushed out due to a lack of being able to test. It lets you change DSM settings live when you have er9x/ersky9x or by recompiling if PPM. Option is used to set the number of channels (4 to 12) as well as forcing 11ms frame rate instead of 22ms for 4 to 7 channels.
This might help your mSRX...
Last edited by hpnuts; Mar 08, 2016 at 12:20 PM.


Quick Reply
Message:

Thread Tools