Thread Tools
Sep 16, 2019, 06:04 PM
Registered User
jims123's Avatar

Dual Use DIY module?


Ok, so I have a couple Q7XS transmitters.. and will soon have two iRangeX IRX4 Plus 4 in 1 Modules.. I'm going to mod one of them at a time soon and start trying to update and mod the firmware on each.

But I was also thinking it would be great if I could modify them both with an added toggle (or slide) switch that would enable one of two different functions for this DIY module..

The new mode/function I would like to switch ON is an XM+ Rx that is currently used as a Wireless Trainer Receiver in MASTER/SBUS mode in the Master Radio. It's soldered to a 5 pin header and slid onto the module pins within an almost empty JR Bay right now, See this link to see what I'm talking about :

https://www.instructables.com/id/Sim...sing-SBUS-Rec/

but I'd like to also use the DIY too.. so with an added switch selecting either this Linker+ equivalent in "TRAINER ON" position, I's like to switch it OFF to enable the DIY Module..

Do you think this would be possible to do this and have a reliable end-result:

I figured I could de-solder the DIY's header and re-move (the pin 3) that is feeding the plated thru BATT+ hole to insulate it from the DIY module then use a simple single pole A/B switch to control which device gets the +7vdc BATT Power from the Radio, either the XM+ or the DIY 4:1 by switching that third pin up from the bottom to either one destination or the other.. What say , could this work? Is there an easier way?

https://github.com/pascallanger/DIY-...ransmitters.md

A key goal would be to be able to swap the modified Dual Use DIY modules between the two radios so I can troubleshoot more easily as well..
Sign up now
to remove ads between posts
Sep 17, 2019, 12:24 AM
Registered User
3djc's Avatar
@jims123, wouldn't it be nice if the great Multi guys where working on something like that (just in a more easier way) and that would be planed for OpenTX 2.3.1 ???? What did I just spoil something ?
Sep 17, 2019, 12:32 AM
Pascal
hpnuts's Avatar
...
Last edited by hpnuts; Sep 17, 2019 at 12:48 AM.
Sep 17, 2019, 01:16 AM
Pascal
hpnuts's Avatar
Quote:
Originally Posted by ddano007
Because on commercional 4-in-1 modules the power of cc2500 is around 60mW.
Why do you say that? The 4 in 1 RF module is well capable of 100+mw but you have to use the right components around it: https://www.rcgroups.com/forums/show...&postcount=284
Pascal
Sep 17, 2019, 01:36 AM
Registered User
jims123's Avatar
Quote:
Originally Posted by 3djc
@jims123, wouldn't it be nice if the great Multi guys where working on something like that (just in a more easier way) and that would be planed for OpenTX 2.3.1 ???? What did I just spoil something ?
Heck yes it would be nice and a lot easier if they'd add a Wireless Trainer Linker into it sure!..

.. but I'm sure they'd do a better job, and I suspect if I just switched the +BATT Power Pin alone the loading on the other pin which I believe is the SBUS signal pin likely would mess something up.. Anyway it was just a thought and by the time I get the things loaded with new firmware.. theirs may be on the market..

Just got this look at the inside of the actual iRangeX 4 in 1 Plus module (below) and it would be harder to hack in an XM+ Rx than I'd hoped.. If I could get a schematic I'd reconsider, but with the Mini-USB, Rotary Switch and the other pins close by or in the way, and with the possibility someone might put out a DIY module version with a Wireless training receiver in it, I'll stick to just updating the module firmware for now..
Last edited by jims123; Sep 17, 2019 at 01:10 PM.
Sep 17, 2019, 06:07 AM
Registered User
ddano007's Avatar
Quote:
Originally Posted by hpnuts
Why do you say that? Pascal
I`m sorry, but based on such info as this
https://www.rcgroups.com/forums/show...postcount=3609
and this
https://static.rcgroups.net/forums/a...57.23%20am.png
So my concusion was, that 4-in-1 modules from Cina webshops are not working on cc2500 at 100mW

Quote:
Originally Posted by hpnuts
The 4 in 1 RF module is well capable of 100+mw but you have to use the right components around it: https://www.rcgroups.com/forums/show...&postcount=284
Pascal
Well, thanks, if antenna is the only problem it`s easy to change it.
Sep 17, 2019, 06:47 AM
Pascal
hpnuts's Avatar
RF is not easy as one can think. It's easy to mess everything up. Just a bad connection, bad length, bad soldering, bad shield, bad ... and you lose a lot of output power.

Pascal
Sep 17, 2019, 11:48 AM
Registered User
Yeah we even created another thread about it RF power of the Multimodules.

On FrSky protocol I was getting ~55mW before replacing the wire and got 80mW after. The Q X7 puts out ~133mW (at least after I replaced the antenna with an SMA to measure it) so I'd say that they're not the same output at least on my iRangeX, but replacing the wire does add 50% more power output.
Sep 17, 2019, 02:51 PM
Registered User
I've put opentx 2.3.0 RC4 on my Taranis Q X7 and now with the multimodule, I get "RF signal critical" every time my receiver establishes a connection. I'm not sure what's changed internally in opentx but it seems what's happening is this:
  • Receiver connects, transmitter shows TRSS and A1 values on the model telemetry page
  • opentx sets the telemetry streaming flag
  • opentx reports "RF signal critical"
  • Receiver sends RSNR telemetry (<1s after connect), multiprotocol forwards it
  • opentx RSNR shows up, signal is fine

I can't remember the order that things pop in on opentx 2.2.x but I would not get the rssi warning at the beginning of every new battery. I feel like the right solution is if for RSSI to be promoted to a TelemetrySensor in opentx, so that it can tell the difference between an RSSI of 0 and no RSSI but there's no way that would happen on RC4. Same goes for considering a value of 0 RSSI to be invalid instead of critical. Any idea how we can get this fixed before opentx 2.3.0 releases?
Sep 17, 2019, 05:48 PM
Registered User
Quote:
Originally Posted by CapnBry
I've put opentx 2.3.0 RC4 on my Taranis Q X7 and now with the multimodule, I get "RF signal critical" every time my receiver establishes a connection. I'm not sure what's changed internally in opentx but it seems what's happening is this:
  • Receiver connects, transmitter shows TRSS and A1 values on the model telemetry page
  • opentx sets the telemetry streaming flag
  • opentx reports "RF signal critical"
  • Receiver sends RSNR telemetry (<1s after connect), multiprotocol forwards it
  • opentx RSNR shows up, signal is fine

I can't remember the order that things pop in on opentx 2.2.x but I would not get the rssi warning at the beginning of every new battery. I feel like the right solution is if for RSSI to be promoted to a TelemetrySensor in opentx, so that it can tell the difference between an RSSI of 0 and no RSSI but there's no way that would happen on RC4. Same goes for considering a value of 0 RSSI to be invalid instead of critical. Any idea how we can get this fixed before opentx 2.3.0 releases?
Hey! Which protocol are you using? And which version of the MPM firmware?

The odd thing that the “telemetry streaming flag” is actually a simple test for non-zero RSSI.
So it is probably not zero, but a very low non-zero value.

Dis you have the same issue with other 2.3.0 versions before? Which was the last one working properly for you?
Sep 17, 2019, 07:34 PM
Registered User
If I understand it correctly this is for FlySky protocol. FlySky returns negative RSSI numbers ( - 90; - 60), so openTX is using RSNR instead of RSSI for all warnings.
Sep 17, 2019, 09:34 PM
Registered User
Quote:
Originally Posted by pafleraf
Hey! Which protocol are you using? And which version of the MPM firmware?
Oh geez, I had been looking at source for so long I forgot to include it was the FlySky AFHDS 2A protocol with MULTI_TELEMETRY. My MPM firmware is from last week, 1.2.1.74.

TELEMETRY_STREAMING in the opentx context means that "any telemetry item has been received within the last timeout period", and the timeout period for this protocol is TELEMETRY_TIMEOUT10ms, which oddly enough is 1 second. So the first item comes in with the TX's RSSI and A1 (receiver voltage) and it sets the timeout. The RSNR doesn't come into the transmitter from the receiver for a long time (up to a second!) so there's this giant gap where opentx is thinking it has telemetry because the flag is set, but the RSNR it relies on isn't available yet. The "rssi" in opentx is 0 because it is still waiting for a value, not because it is a negative or low value.

It's a race condition in the slowest sense of the phrase. OpenTX now requires that the receiver RSSI be among the first values it receives or else the streaming flag will be set and the transmitter will complain about critical signal on the next backend loop.
Sep 18, 2019, 02:35 AM
Pascal
hpnuts's Avatar
Quote:
Originally Posted by CapnBry
Oh geez, I had been looking at source for so long I forgot to include it was the FlySky AFHDS 2A protocol with MULTI_TELEMETRY. My MPM firmware is from last week, 1.2.1.74.
What sensors do you have to go with your AFHDS2A equipment?
I've reworked both Multi and OpenTX to correct few current issues and add a lot of sensors on this protocol. I'll be happy if you could test the changes as you seem to be into it and able to build your own version of OpenTX.

Pascal
PS: I do also have your behavior where the radio complains when you plug the RX.
Sep 18, 2019, 03:50 AM
Registered User
3djc's Avatar
Quote:
Originally Posted by CapnBry
Oh geez, I had been looking at source for so long I forgot to include it was the FlySky AFHDS 2A protocol with MULTI_TELEMETRY. My MPM firmware is from last week, 1.2.1.74.

TELEMETRY_STREAMING in the opentx context means that "any telemetry item has been received within the last timeout period", and the timeout period for this protocol is TELEMETRY_TIMEOUT10ms, which oddly enough is 1 second. So the first item comes in with the TX's RSSI and A1 (receiver voltage) and it sets the timeout. The RSNR doesn't come into the transmitter from the receiver for a long time (up to a second!) so there's this giant gap where opentx is thinking it has telemetry because the flag is set, but the RSNR it relies on isn't available yet. The "rssi" in opentx is 0 because it is still waiting for a value, not because it is a negative or low value.

It's a race condition in the slowest sense of the phrase. OpenTX now requires that the receiver RSSI be among the first values it receives or else the streaming flag will be set and the transmitter will complain about critical signal on the next backend loop.
I've PR a fix, should be in next nightly/pr
Sep 18, 2019, 07:19 AM
Registered User
Quote:
Originally Posted by hpnuts
What sensors do you have to go with your AFHDS2A equipment?
No real sensors, just iNav telemetry with all of its sensors. I've also tried it with a straight FlySky FS-IA6B receiver and it does the same thing, since it only relies on there being any telemetry sent, including the TRSS (transmitter's received signal strength). On FS-IA6 (non-B), it gets the "RF signal critical" warning continuously, since that receiver never sends RSNR so the opentx RSSI stays 0 all the time. It does send LQI though, but opentx can't use that without changing source code.

It has the same behavior unplugging and replugging the RX if that's what you mean. Every time it transitions from "Telemetry lost" to active it has the same condition where the TRSS comes in first and triggers an "online" state, but there's no RSSI value yet. This all could be avoided if opentx reclassified rssi==0 as being "offline" status, instead of it considering 0 a valid signal strength. I'd be happy to check out anything you want. I'm a software dev myself and can build opentx / multiprotocoltx and have oscilloscopes and logic analyzers at my disposal, although in this instance it is already clear what's happening.

@3djc: That seems like a valid fix, to only pass TELEMETRY_STREAMING check if RSNR comes in. This must have been the way it was in 2.2.x somehow, because my FS-IA6 (non-B) that doesn't send RSNR would act-- it never thought it was receiving telemetry even though it was getting RX battery voltage and LQI from the receiver. However, I'm not sure about altering the value coming in:
Code:
        value = -value;
        value = 135 - value;
The way it is now matches what a FlySky receiver would show and the values don't undergo any sort of magic transformation. I feel like really opentx signal strength should be pulled like:
Code:
 if (id == FS_ID_ERR) { // <<-- NOTE: ERR not SNR
    telemetryStreaming = TELEMETRY_TIMEOUT10ms;
    telemetryData.rssi.set(100-value);	
}
This way, the telemetry displayed matches what is shown on a FlySky receiver exactly and opentx gets a 0 -> 100% range signal meter it wants, and it makes it work with receivers that only send LQI and not SNR (although I don't know if there are FlySky receivers that send SNR and not LQI?)


Quick Reply
Message:

Thread Tools