openrcforums

The DDOS filter is definitely still causing problems if you're writing a long post or a post that you are taking a few minutes to finish. I'm having to make sure I copy everything each time if I'm not doing a small post now as more often than not it resets the connection when you go to post losing t...

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...

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 ...

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.

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.

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,...

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. ...

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...

Ahhh, now it makes sense

Will have a go now...

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

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.

Ah, well I tried anyway and changing the RX_Num did disconnect the receiver as expected and the link restored when I switched it back again. I have restored all the changes though and left the new global ID configured and after 50 cycles it seems to be fine. I stopped at 50 as my hands are now start...

OK, so it was me - I hadn't uploaded the new firmware to the module with the reset global ID! However, I did the update and did a test again after re-binding. I got to 24 cycles before a bad link cropped up so I kept going and got another 100 cycles that were clean with a good link up. So then I re-...

jhsa wrote: ↑Mon Jan 22, 2018 5:26 pm If you change the global ID you need to rebind. That is the ID the receiver stores when you bind it to the module. If you change it, the receiver is not bound anymore

João

That's what I thought - seems strange it still links up???

I'll re-bind anyway and re-test...

OK, so I tried a different RX_Num and re-bound the receiver and had the same link problem within 3 power cycles. I altered the Global ID in _config.h and without re-binding I've had enough good links without fail to lose count. It seems a little odd that with the line set to #define FORCE_GLOBAL_ID ...

I'll try a test on a different RX_Num now just to confirm but I think I did already try it. How does the link actually establish when the receiver is powered up? Is the module always sending a packet out and when the receiver is powered up it communicates with the packet that's been received and est...

Still the same unfortunately. First link was good, second and third bad.

Reset the third by swapping sub protocol again.

Just tried with failsafe disabled and first four power cycles were a bad link with the servo movement being rough.
Fifth cycle was a good link and stayed smooth no problem at all.

I've recompiled and uploaded and the first power up was a bad link. Second, third and fourth were fine but the fifth is a bad link again and isn't stabilising. Tried the sub protocol change again and switching to PPM_IBUS I lose servo movement completely as I'd expect, then if I switch to PWM_SBUS i...

OK, test with telemetry disabled in the module seems to give the same results. First power on was a two second delay before smooth servo movement was apparent. Second power up was good, as was the third. The fourth is showing the servo jumping around so a bad link has been established but it's not i...

planger wrote: ↑Mon Jan 22, 2018 12:55 pm Leigh,

Is the only way to see a bad link is through RSSI/TSSI?
I would like to see if you could disable the telemetry in Multi _config.h file (and therefore loose the RSSI/TSSI information) to see if it helps.

Pascal

Thanks Pascal,

I'll give that a try now and do some more testing.

Thanks Mike I'll keep an eye out for it.

Incidentally I just did a test with the receiver on bad link up I walked downstairs and to the other side of the house and at the farthest point it stabilised and gave great RSSI/TSSI.
May be coincidence but will test more tomorrow...

Still trying to work things out on this. Mike, is there a way without changing the coding that I can access the raw telemetry stream coming in from the receiver in real time at all? I would like to be able to see the Rx Noise, SNR and Error rate as the problems are coming through to see if I can get...

Well, the new IRX4+ module has arrived and has been upgraded to the latest version of Multi (1.2.12) and a quick test just in the same room. I did the same system as before where I power the Rx up, wait for stable link and servo movement then power down, wait for telemetry lost signal then repeat th...

Has anyone tried these receivers at all? https://www.banggood.com/RX-F82DA-8CH-Receiver-compatible-Frsky-X9D-Plus-DIT-DFT-X9E-X12S-Transmitter-for-RC-FPV-Racing-Drone-p-1232673.html Just had one land and have set it up and all seems to be working fine. Seems a little bit sensitive on the antenna pos...

Well, tested binding with the frequency adjusted to -75 and more often that not it doesn't give a good link up at all. In fact I seem to be struggling even more than before after re-binding. I tried changing the Rx_Num but that doesn't seem to make a difference at all. I have tried a test where I se...

Ok so from what I understand 650 is the upper value and -800 is the lower value. Above or below it becomes choppy or disconnect. Then the middle value is (650-800)/2=-75. Try to set the value to -75, then rebind your RX and test to see If you can reproduce the issue (I'm thinking you'll be able to)...

Quick update... After setting the value at +780 I was able to get three good links in a row before a bad link came up. I then did a sweep up to 1024 and on the way back down past around 650 it settled down and maintained a good link. If I went back up to the top it would drop out again but I could r...

By the way, have you tried yet to change the fine tuning on CH15? Pascal I've just tried it and by pure chance the first power up of the Rx was a poor link so I scanned down (to -1024) then back up all the time moving the servo so see when things smoothed out. I got to +780 and it smoothed straight...

Also, I've been power cycling my RX dozens of time and I can't reproduce the issue of jerky servos and RS RSSI is steady at 75. It's happening at power up right or I need to wait to see the issue happening? Pascal It is always when the receiver is powered up that the problem will occur. I've found ...