|
|
|
Thread OP
|
Well... I got the full SPI port hooked up for both modules. The primary RF module is the one closest to the top of the transmitter. The secondary module is the one closest to the center of the transmitter.
So, the primary module is transmitting every single packet at roughly 10ms. There is some variation, but that is to be expected from 802.15.4 protocol which uses a back-off exponent to randomize the start of each transmission to add some time diversity. It seems that the secondary module is communicating about every 20ms or so. I am not sure if this is a transmission or reception (I need to look at the SPI commands to determine that). One thing for sure is that whatever is going on with the secondary module, it is the main cause of the receiver not getting data, resulting in lost packets. See the screen shots. Green shows the secondary module packets that are skipped for some reason. Red shows the packets that were sent, but not received. You can download the full capture of the primary module here: http://www.xtremepowersystems.net/do...6_R3_SPI_1.zip You can download the full capture of the secondary module here: http://www.xtremepowersystems.net/do...6_R3_SPI_2.zip These captures were done in the DEFAULT (not DUAL PATH) mode with a single R3 receiver. The IRQ can toggle for other states besides the receive interrupt, but you can clearly see when the IRQ does not occur that the receive buffer is not transferred. I didn't capture the IRQ on the DS-16 because I am only concerned with transmissions. I am only using Failsafe disabled in my testing, however, enabling it made no difference. So, I guess what I need to determine now is if the secondary module is receiving telemetry data coming back from the receiver or sending something else to the receiver. This could be something a simple as one RF module interfering with the other. I know that our DivBee module can have this problem and I have noted in our FCC documentation that co-located transmitter antennas must be separated at least 20cm apart to prevent this. A couple of people asked to see the wiring I am using. So, I took a picture of that. ImagesView all Images in thread
|
Last edited by JimDrew; Dec 05, 2018 at 07:27 PM.
|
|
|
||
|
Quote:
https://www.rcgroups.com/forums/show...3-18-Receivers Those test were done with REX FW1.10. The last REX update 1.12 fix a lot of bugs in exbus and timing issues. i set failsafe to 30s with period 10ms on a rex, 2 nights ago, and after the tx was turned off, and the exbus disappeared, the REX repeated the last udi frame 4 times, then the udi output stopped. The pwm continued at 10ms, until i turned the tx back on (before the failsafe. |
|
|
||
|
|
Thread OP
|
Yep, what you have posted is exactly what I have captured as well. I think the problem has to do with the secondary RF module (using DEFAULT mode, not DUAL PATH) being interfered with or interfering with the primary RF module. I did a quick check in DUAL PATH mode and see that the same issue occurs, but the packets are completely different from DEFAULT mode and both RF modules are outputting/receiving data and losing packets. I think the issue is either a setup issue (not checking PLL lock after changing the channel - and prior to doing some other command) or interference between modules. I ran into both of these issues myself when developing our RFU. I might disable the power from the secondary module and see if the system starts complaining about no signal and look at the receiver loss.
I ended up putting connectors on the SPI port connections so I can have the SPI ports available in the future if needed. |
Last edited by JimDrew; Dec 05, 2018 at 10:52 PM.
|
|
|
|
|
After doing about 100 quick captures, i would estimate that 10-20% of the events have a interrupt, and some form of reception started, but failed. And 80-90% were events that had terrible headers or were completely missing RF frames.
|
|
Last edited by cravenjw; Dec 05, 2018 at 10:45 PM.
|
|
|
Thread OP
|
ACK! I soldered the shield back on already! I figured it was a TI chip because that is what they used in all of their receivers. I will see if I have better pictures where I can read a part number. It is very rectangular, not a typical square chip.
::edit:: It has a SE2431L on the part. http://www.skyworksinc.com/Product/933/SE2431L Our DivBee module uses the RFX2401 (not to be confused with RFX2401C, there is a huge difference!). The 2401C is a power hog, has horrible harmonics, etc. I am not sure why they still produce that part. The RFX2401 (NMOS version) is only available through special order. I happen to have reels of them inventory. ImagesView all Images in thread |
Last edited by JimDrew; Dec 05, 2018 at 11:26 PM.
|
|
|
|
|
Following with great interest!
JIm,
Just a note that may or may not be of interest. Gene and I have been working with his X24 and have come across something odd. My X24 is set up with two R3/RSW receivers in UDI @your recommended settings. Both receivers are solid and no (or few) lost frames showing. When we try his out with the newer REX receivers we get almost immediate counting of one or both receivers at a fairly rapid rate of frame loss. Have swapped out receivers, leads, and re-verified all the settings to match those in my R3s. The REX receivers have the latest 1.12 update. I sent you two REX and two R3s with my X10 and X24. While you have them, can you try the REX receivers hooked up the X24 (One in normal and one in clone) with TX in default and see what results you get and your interpretation? I appreciate the work you are doing. Hopefully we can get something that works here in the hell hole of Las Vegas or I am going to have to move away from here..... |
|
|
Thread OP
|
Yeah, when Gene was here (as well as the AMA event) his receiver packet loss was insane. I have many customers experiencing the same thing though with REX recievers. It seems the R3 recievers fair much better than the REX receivers. I will let you know what I see with your stuff.
|
|
|
|
Guys
Appreciate the detective work here... Seems that more testing is needed to reconfirm best path forward. Appreciate if conclusions or options for users are restated once there is more certainty. I use planes with either XPS24 and just plain receivers. I was about to patch my XPS24 with the latest firmware for Exbus in order to get the 24 channels, but seems I should wait before doing so. Thanks. |
|
|
Thread Tools | |
Similar Threads | |||||
Category | Thread | Thread Starter | Forum | Replies | Last Post |
Alert | Customers outside North/South America PLEASE READ | Xpress.. | Hitec/Multiplex USA | 0 | May 17, 2018 01:08 PM |
Discussion | A plea to the community. | Joexer | Model Aircraft & Drone Advocacy | 1 | Dec 23, 2015 08:37 PM |
Discussion | Plea To DJI for better Inspire Customer Service | jfro | Multirotor Drone Talk | 5 | Apr 13, 2015 10:11 PM |
Discussion | Need some info about radios-Pleas read | mrhodes | Radios | 2 | Feb 12, 2014 12:55 PM |
Discussion | From Customization to Custom Builds: Addictions and Community (READ POST #1) | ChristianGeek | Multirotor Drone Talk | 184 | Jan 08, 2014 08:25 PM |