openrcforums

What module type do you have? We can extract the ID. It's really easy if they are on USB.

I have two, an original Banggood stm32 (the one with the USB port) and the one which arrived on Saturday is the iRangeX IRX4+ again with the USB port.

So in Multiprotocol.ino, uncomment the line #define DEBUG_SERIAL
Flash the firmware with this line changed
The module will not start (led off) which is normal. In the Arduino IDE, open the "Serial monitor" (ctrl+shift+M).
On the monitor you'll see the module starting and printing it's ID.

So that's with the usb to ttl connected yes?

No, with the USB cable plugged at the back of the module.

Ahhh, now it makes sense

Will have a go now...

This is only going to work if you are using the "Upload via USB" method from the arduino environement which I supposed you were doing but now I have a doubt...

No, I'm using upload via TX but I just did a quick test and it seemed to put data out via the serial port.
Am just re-compiling without the forced GUID...

OK, so did the reflash of the USB bootloader and did a check and the stock GUID on the board seems to be 7375be3b.

Didn't do any other tests while I had that linked up via serial but I re-flashed the new code with the custom GUID and will do some more tests now I have a toggle switch for the power.

The only thing I was wondering is could the receiver be struggling with higher numbers for the Global ID? So it almost connects but can't store the number fully so doesn't connect properly most of the time?

Just mulling over what the root cause could be, but I'll know more when I've done some real testing and can reliably say it's not causing link problems any more...

Quick update...

Had a single bad link out of 50 cycles. WAY better than before but still there occasionally it seems.
That sort of frequency of failed links I can handle, but I would still love to know what the root cause actually is.
As far as I know the firmware is now up to v1.8 on the receivers, but I have an STLink on the way to try and download the firmware and see what I can pull apart. I also have firmware version 1.6 for the IA6b receiver from the Deviation forum so I can try and upload of that to see what I get from that too.

Just a little thing too Mike. The external voltage sensor which seems to appear at T1 and FasV has the decimal point too far to the right. So whereas I should see 11.24v I'm seeing 112.4v - probably something very simple but handy to know if you are updating the version soon.

Could you also dump the ID of your second module?

planger wrote: ↑Tue Jan 23, 2018 8:30 am Could you also dump the ID of your second module?

Have just done that and the ID has come up as 704e8838. So a similar sort of range as the other one.

I'm just wondering if the module is swamping the Rx, since you did that test where you moved away.
As a test, in "multiprotocol.h", you could try changing he line:
#define A7105_HIGH_POWER A7105_POWER_7
to
#define A7105_HIGH_POWER A7105_POWER_5
to reduce the power.

Another (simpler) test is to use the range check option as this switches the output power down, see if that gets the link working correctly.

Mike

MikeB wrote: ↑Tue Jan 23, 2018 12:53 pm I'm just wondering if the module is swamping the Rx, since you did that test where you moved away.
As a test, in "multiprotocol.h", you could try changing he line:
#define A7105_HIGH_POWER A7105_POWER_7
to
#define A7105_HIGH_POWER A7105_POWER_5
to reduce the power.

Another (simpler) test is to use the range check option as this switches the output power down, see if that gets the link working correctly.

Mike

That's a very good point Mike. I'll see what difference I get in range check mode.

Hopefully getting to the root cause of this now...

OK, test set up with transmitter around 18 inches from the receiver.
First test was full strength with my custom GUID multi firmware and I could not get it to fail.
Flashed the stock GUID firmware and managed to get a fail to occur. While this was happening I switched on range check and although the telemetry didn't stabilise it smoothed out the servo signal quite a bit.
Did a few more cycles with range check enabled and managed to get another fail despite being in range check mode.

I wonder if what may be happening is a combination of circumstances?
When too close there's some swamping that occurs and with the stock generated GUID it is perhaps missing the link fully due to not being able to fully interpret the Tx ID on the Rx. This doesn't seem to be the case with the custom GUID so despite the chance of swamping it can communicate enough with the receiver to stabilise the link successfully with the number being either lower down in value or just because it doesn't contain any upper hex values?

Complete speculation but it seems there's a definite link to having the custom Global ID and stability of the connection.

I popped a post on the RCGroups thread to see if there was anyone else running these receivers that could join in the test but I've not had any response as yet...

I've setup my module to use your ID 7375be3b. From there I've power cycled at least 30 times my receiver with a servo sweep running on the radio. I haven't got a single issue where you usually get one in less than 10 tries...
This is pointing in my eyes to an issue on the RX(s). Do you have the hardware to do a SPI dump of a receiver? That could help to understand what the RX is struggling with.

MikeB wrote: ↑Fri Jan 05, 2018 1:32 pmNew (test) versions of ersky9x will have the option byte with the 0x80 bit always set when in AFHDS2A protocol.

Mike, Is this available?
As far as I can see 221g2 still needs to select T-Rate to get the telemetry running.

Pascal

Should be in "g3". I have a problem editing the first post of the test versions thread, so "g3" is in the fifth post of the thread.

Mike.

planger wrote: ↑Wed Jan 24, 2018 3:46 pm I've setup my module to use your ID 7375be3b. From there I've power cycled at least 30 times my receiver with a servo sweep running on the radio. I haven't got a single issue where you usually get one in less than 10 tries...
This is pointing in my eyes to an issue on the RX(s). Do you have the hardware to do a SPI dump of a receiver? That could help to understand what the RX is struggling with.

I don't have anything to my knowledge that I could use to pull and SPI dump off the receiver. May be worth it though for test purposes, I just need to know what I need to buy.
I do have an STLink adapter coming soon though but I was going to use that to try and pull the firmware from the receiver and compare against the one that Goebish has uploaded some time ago which is v1.6 as far as I know - https://www.rcgroups.com/forums/showthr ... -a-ST-Link .

I have tried setting up a model on one of my existing planes that runs an older IA6B receiver and slightly different lipo sensor (FS-CVT01 rather than the newer FS-AVT01) and where the AVT01 shows for example 110.4v on FasV (for an 11.04v Lipo) the CVT01 shows 11.0v but flickers incredibly fast between that and another figure but I'm not able to see what it is the flickering is that quick.
I do get the feeling that although the receivers are all supposedly at the latest version according to my i10 transmitter there could be some variance in them so if I can get a good firmware onto them that is reliable I think we should be getting somewhere.

MikeB wrote: ↑Wed Jan 24, 2018 3:59 pm Should be in "g3". I have a problem editing the first post of the test versions thread, so "g3" is in the fifth post of the thread.

Mike.

Mike,
I've noticed that I still need to select a different setting to the default still though and go down to what would have been T50, but now the T isn't there. If I leave it at the default 50 I get no telemetry coming through. This is running on "g3".

I'll look at the option setting, it was supposed to set the 'T' bit!
If you could do some raw telemetry logs with the different receivers/sensors I will investigate the FasV display problem.

Mike

Will create some logs in the morning.

It seems the sensor is the issue as with the same receiver I get the two different results depending on which sensor I have connected.
I can't seem to find any information as to what the difference is between the two sensors other than the connection to the receiver needs an adapter on the newer AVT01 sensor.

Will get some of my other receivers bound and check on those too just to rule that part out.

I've found out why the T-rate change isn't working, that will get fixed in "g4".

Mike

Here you go Mike. Two raw logs - one with the FS-AVT01 which reads seemingly to a more accurate decimal level so has the decimal point one digit too far right and one with the FS-CVT01 which reads to a single decimal point but flicks around a bit.

I have just had a thought though as I've typed that. If the CVT01 is only delivering 3 bytes instead of 4 could that be why the figure is fluctuating as it's leaving random bytes where the MSB byte should be?
Will have a look a the raw log to confirm but I've attached them both to the post for you.

I don't see any files...

Sometimes I love how that happens when you get the DDOS stick after posting!

I'll try that again...
Looking at the raw logs I have just noticed that the sensor ID comes through different between the sensors though. The AVT01 identifies as 0001 and the CVT01 as 0301.
They do read different voltages too from the same source but that's a known thing on these sensors, they're not massively accurate and normally under-read.

The IDs are "little endian" so are 0100 and 0103. I don't process the 0103 one, so if you are seeing a value displayed with the CVT01, I'm not sure why this is. It seems you have the FasV value being filled in from somewhere else, do you have a scaler set up to write to the FasV value?
I'll add code to handle the 0103 ID.

Mike

MikeB wrote: ↑Thu Jan 25, 2018 2:56 pm The IDs are "little endian" so are 0100 and 0103. I don't process the 0103 one, so if you are seeing a value displayed with the CVT01, I'm not sure why this is. It seems you have the FasV value being filled in from somewhere else, do you have a scaler set up to write to the FasV value?
I'll add code to handle the 0103 ID.

Mike

I'll double check but I'm sure I cleared the scaler out as I was using one to shift the decimal point on the AVT01.

I'm just seeing if I can find any reference to the sensor ID's to make sure it's not something that would switch around depending on the age/model of sensor.

EDIT: Seems the AVT01 was designed for the IA10 receivers and the CVT01 for the IA6b. I've only used one IA10 and that was with the AVT01 but on the IA6 I used an adapter cable to get the plug into the sensor port as it's a mini connector be default on the AVT01. Obviously using my i10 radio it just works out what it is and gives the data back in the right format whereas apparently on the i6 transmitters it reads the CVT01 as external voltage and the AVT01 as a second internal voltage along side the RxV. Probably explains the address difference and may explain the difference in voltage reading too.

OK, the voltage seems ever stranger...

I checked my scalers and I had indeed left one in there taking the data from T1 and scaling it and I'd inadvertently left it's destination as VOLTS. So I was seeing the voltage information from the CVT01 sensor AND the scaler from T1 too.

Now here's the odd thing. I have cleared the scaler down and checked the input from the CVT01 and it's rock solid and pretty much spot on for the lipo voltage coming through on FasV. However, when I swap over to the AVT01 FasV is blank and doesn't recognise any telemetry input, but T1 displays the voltage with no decimal points (1191 at the minute).

So, it seems the AVT01 is being put into the wrong telemetry slot but the CVT01 is actually working fine...

OK, I've spotted another bug in picking up the sensor ID value, so I'm not processing them correctly.
I'm just doing a build of ersky9x, so I'll hopefully post a "g4" shortly.
The first 3 custom telemetry values (Cus1,2 and3), will contain the error rate, SNR and Noise values from the telemetry.

Mike

Edit: Posted (on the fifth post of the test vesions thread).