| Hi Eric,
Now everything makes perfect sense! Your response cleared a lot of fog in my head in connection to the new Spektrum parser. I will take a look at the code myself to get a solid understanding of the whole protocol.
I will test everything as soon as I get back home (tomorrow) and let you know about the results.
Thank you so much for clearing the whole thing up. I really appreciate it!
Kind regards,
Marko
PS: Are you located in America or have you been working on my problem till 5AM? In either case a thank you beer won't be enough! :-)
On Aug 29, 2010, at 4:23 AM, Eric Parsonage wrote: Marko
I wrote all the stuff below then realised I can just test what you did.
If you bind on a 7 channel receiver and then plug the satellite into lisa you get the result you observe. I did this using a JR transmitter with a DM9 module.
What you need to do is bind on lisa do this and all will be fixed.
Now here is what I wrote before I tested the problem. Read it because you will glean some useful information from it.
Best regard
Eric
I hope you are still awake so we can work this out. Here are my first thoughts.
1) Marko did you bind on Lisa ? This is important because when you bind the receiver sets the protocol that you will be using. We have Lisa pretend to the satellite receivers it is a 9 or 12 channel receiver. It does this by sending a pulse train to the satellites at bind time. The master rf receiver (we set the first satellite to be a master rf receiver) then transmits this to the transmitter during the bind handshake. Now if you bind on a 7 channel receiver the protocol the transmitter send to the receiver is slightly different than that for a 9 or 12 channel receiver.
- no throttle stick movement was observed in the RC/PPM telemetry data (no matter what kind of channel mapping I used - e.g. booz_radio_control_spektrum_dx7se.h),
2 ) All spektrum receivers have the same mapping for output so we no longer use those headers (sorry you where wasting time with those) the mapping will be.
#define RADIO_CONTROL_THROTTLE 0 #define RADIO_CONTROL_ROLL 1 #define RADIO_CONTROL_PITCH 2 #define RADIO_CONTROL_YAW 3 #define RADIO_CONTROL_GEAR 4 #define RADIO_CONTROL_FLAP 5 #define RADIO_CONTROL_AUX1 5 #define RADIO_CONTROL_AUX2 6 #define RADIO_CONTROL_AUX3 7 #define RADIO_CONTROL_AUX4 8 #define RADIO_CONTROL_AUX5 9 #define RADIO_CONTROL_AUX6 10 #define RADIO_CONTROL_AUX7 11
- Futaba has a throttle assigned to channel 3 while I believe (not certain) that Spektrum has throttle assigned to channel 1,
3) The order that the channels appear in each frame can be any order but we now use the channel number that the transmitter sends with each piece of channel data. So if when you bind to a spektrum receiver if the throttle outputs out of the throttle channel marked on the receiver then this should be the same on Lisa. (the use of the channel number data is why we no longer need the headers for assigning channel order)
4) Do you have your transmitter in heli mode ? where the throttle and collective are mixed ? So the throttle stick is actually a collective stick and the throttle channel is governed by a mix from collective to throttle ? Possibly you might have a safe mix where you can play with collective without the motors spinning up set.
SO HERE IS WHAT I WOULD LIKE YOU TO TEST (i wrote this in caps so you would notice :) )
1) Bind on Lisa (this is most important for reasons stated above)
2) Have you got a receiver so you can check that the channel order that the receiver gets from the transmitter is what is expected (ie wiggle throttle stick moves the servo plugged into the receiver in the location marked throttle etc) This will also check if we have a problem with throttle collective mixing as if you cant wiggle the throttle stick and get a servo to move then it must be mixing.
3) Check the mixing with throttle collective if you are in heli mode and any other failsafe stuff.
4) Check the telemetry and confirm the order of the channels is as above for the other channels at least.
5) if 1 and 2 don't help we need to record some serial data there is space in the spektrum protocol for transmitting 14 channels but they only use 12. possibly they do some messing with these if that is the case with some data it should be easy to fix.
In any case get back to me. If you have fixed the problem I would like to know. If you have more information that might help to fix it let me know.
Eric
Marko
On Aug 28, 2010, at 4:42 PM, Eric Parsonage wrote: Marko
The new satellite code has been committed. Would be great If you gave it a whirl. You can use 1 or 2 satellites. It works with all the 5,6,7,9 & 12 channel transmitters I could get my hands on.
If you use two satellites you are going to have to have some ugly wiring as UART5 pin is currently used by the imu. So to begin with try with only one. You no longer have to create a header file for whatever Spektrum/Jr transmitter you have and you can use up to 12 channels. All you need do is connect your receiver to lisa and bind it on lisa (to do this you need to connect pin PC3 on the ADC connector to ground while you power up your lisa the process from then is the same as when you bind any spektrum receiver) .
Hopefully you are using the new XML makefile section for your airframe. Here is the firmware section of my airframe to get you started. If you get this working and really want to try two receivers I can explain that to you too.
<firmware name="rotorcraft"> <target name="ap" board="lisa_l_1.0"> <define name = "RADIO_CONTROL_MODE" value = "RADIO_CONTROL_AUX2"/> <define name = "RADIO_CONTROL_KILL_SWITCH" value = "RADIO_CONTROL_GEAR"/> </target> <subsystem name="radio_control" type="spektrum"/> <subsystem name="actuators" type="heli"/> <subsystem name="imu" type="b2_v1.1"/> <subsystem name="gps" type="ublox"/> <subsystem name="ahrs" type="cmpl"/> </firmware>
You can change the allocation of your switches any of the following are valid choices (as long as they exist on your transmitter we can't yet make a 7 channel transmitter into a 9 channel)
RADIO_CONTROL_GEAR RADIO_CONTROL_FLAP RADIO_CONTROL_AUX1 RADIO_CONTROL_AUX2 RADIO_CONTROL_AUX3 RADIO_CONTROL_AUX4 RADIO_CONTROL_AUX5 RADIO_CONTROL_AUX6 RADIO_CONTROL_AUX7
Hopefully that should be enough to get you going.
Eric
On 20/08/2010, at 7:21 PM, Marko Thaler wrote: Hi Reto, Thanks for the info. Cheers, Marko On Aug 20, 2010, at 11:29 AM, Reto Büttner wrote: Hi Marko,
there is some information on the Wiki:
http://paparazzi.enac.fr/wiki/Hardware_Installation#Radio_Devices
http://paparazzi.enac.fr/wiki/Hardware_Installation#General_Electrical_Advice
Cheers, Reto
2010/8/20 Marko Thaler <address@hidden>:
Hello Joe,
All antennas are outside the frame. My comment about carbon fiber vs.
aluminum was meant in terms of a better grounding plane. Since I am a
mechanical engineer/ control systems guy I apologize for my ignorance about
RF attenuation and antenna grounding.
Can someone recommend a good overview resource about ground planes and RF
attenuation for non electrical engineering folks?
Thanks for your help and kind regards,
Marko
On Aug 20, 2010, at 9:17 AM, Gisela Noci wrote:
mmm, Thats even worse than carbon! Any metal is a better shield to RF than
carbon. Better get ALL antenna outside the frame!
Joe
________________________________
From: address@hidden [address@hidden]
on behalf of Marko Thaler [address@hidden]
Sent: Thursday, August 19, 2010 9:38 PM
To: address@hidden
Subject: Re: [Paparazzi-devel] Spektrum Satellite dropping connection
Hello Todd,
Thanks for the reminder about carbon. Luckily, we are using laser cut
aluminum plates for the frame.
Kind regards,
Marko
On Aug 19, 2010, at 12:52 AM, Todd Sandercock wrote:
Also watch out for your standard issues that occur with spektrum and carbon.
Todd
On 19/08/2010, at 3:19 AM, Marko Thaler <address@hidden> wrote:
Hello Eric,
Thank you for the information and for writing a new parser. I am looking
forward to test the new code.
Kind regards,
Marko
On Wed, Aug 18, 2010 at 7:00 PM, Eric Parsonage <address@hidden> wrote:
Hi Marko
There is a bug in the current parser for both lisa and booz when using a
satellite receiver. I believe that the behaviour you are seeing is due to
this bug.
I am currently in the process of writing code to support a pair of
satellite receivers (on lisa) . Hopefully this will be ready in the next few
days.
Regards
Eric
On 19/08/2010, at 2:09 AM, Marko Thaler wrote:
It would be nice to use the main unit and the Satellite together, but at
the moment Lisa/L only supports the use of the Satellite RX with it`s serial
communication protocol. Thanks anyway!
On Wed, Aug 18, 2010 at 6:24 PM, Edixon
Giraldo <address@hidden> wrote:
I was experiencing similar problems with a Spektrum AR7000 Rx. The
reason it was happening to me was because I disconnected the satellite Rx
and was using just the main unit. As soon as I reconnected the satellite, I
never lost connection anymore. I don't know if that is your case, but,
check it out.
________________________________
Date: Wed, 18 Aug 2010 18:11:18 +0200
From: address@hidden
To: address@hidden
Subject: [Paparazzi-devel] Spektrum Satellite dropping connection
Hello everybody,
My setup is Lisa/L with Spektrum Satellite receiver and Futaba T9CP with
Spektrum DSM2 transmitter module. For telemetry I am using 2.4GHz XBee Pro
Series 2 modules.
After a couple of hours of setting up and testing all the systems I have
started to notice the RC link was constantly dropping connection. When the
problem started to occur the quad battery voltage was 11.4V and the
transmitter was at 9.4V. The funny thing is that when I was moving the
sticks the link was solid. However, when there was no stick movement the
connection was dropping out (switching between OK, LOST and REALLY_LOST). I
have reset the board a couple of times and the problem was reproducible.
Has anybody experienced anything similar? What is your experience with
Spektrum system and possible XBee interference (both 2.4GHz)?
I have just recently switched to Spektrum modules because of Lisa/L
support. Previously I was using Jeti Duplex which was rock solid.
Thank you for your help.
Kind regards,
Marko
_______________________________________________ Paparazzi-devel mailing
list address@hiddenhttp://lists.nongnu.org/mailman/listinfo/paparazzi-devel
_______________________________________________
Paparazzi-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/paparazzi-devel
_______________________________________________
Paparazzi-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/paparazzi-devel
_______________________________________________
Paparazzi-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/paparazzi-devel
_______________________________________________
Paparazzi-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/paparazzi-devel
_______________________________________________
Paparazzi-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/paparazzi-devel
_______________________________________________
Paparazzi-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/paparazzi-devel
_______________________________________________
Paparazzi-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/paparazzi-devel
_______________________________________________
Paparazzi-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/paparazzi-devel
_______________________________________________ Paparazzi-devel mailing list address@hiddenhttp://lists.nongnu.org/mailman/listinfo/paparazzi-devel
Paparazzi-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/paparazzi-devel
Paparazzi-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/paparazzi-devel
Paparazzi-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/paparazzi-devel
|