search

FrSkyRC / ETHOS-Feedback-Community

Feedback & suggestions are welcomed here for ETHOS by FrSky
189 stars 85 forks source link

VARIO very unreliable - other sensors seem fine #3940

Closed Jedsters closed 4 months ago

Jedsters commented 5 months ago

I've spent ages trying to work out when this works and when it doesn't but afraid I've totally failed. It seems that more often than not the VARIO isn't detected. Rebinding makes no difference. Deleting and discovering devices makes no difference, sometimes it finds the vario and other times it doesn't. Other devices (GPS, FLVS) are reliable while daisy chained at the same time. Creating a new model makes no difference. Using different rx makes no difference (all ACCST, I've tried S8R and X6R). I've tried 2 different varios (one low precision old one and another a new ADV vario) but that makes no difference. I have no problem using these varios with opentx and my X10 and the same rx.

The best I can do to assist is the following which contains 2 basic models. I used the same S8R, vario, GPS, battery and model id. I was using Play which couldn't detect the vario. I created Play3 detected the sensors and they detected.
Play wasn't detecting the vario. Play3 is detecting the vario. Having created vario.zip I then tested this again, Play3 detected the vario, I selected model Play which didn't have the vario shown so I did a rediscover (without deleting existing sensors) and this time it picked up the vario!! I renamed it Play4 and have uploaded that. i.e. Play and Play4 are identical except Play4 works while Play wasn't detecting the vario at the time. The closest I can come to a suggestion is that when a model is created it detects ok, however a subsequent use of the model somehow stops it working and won't allow it to be rediscovered. Is Ethos somehow creating a sensor conflict with a later reload of a model?

vario.zip

play4.zip

Very much hope you can help as this is driving me nuts.

Much appreciated.

bsongis-frsky commented 5 months ago

Strange issue! Would you contact me on Discord so that I can send you a "special" firmware with telemetry logging enabled (not for flying)?

Jedsters commented 5 months ago

Sure, Discord is a new one on me. I've created an account and opened it in my browser. I assume you can now contact me directly - my id is the same as my github id Thanks

Jedsters commented 5 months ago

OK, this has taken an absolute eternity to pin down and involved me recreating an 8kb model from scratch (why is it always the last thing you add)! But I think I can now reproduce the problem at will. If you create a basic model, add a screen (I used the last one in the list in 1.5.6, i.e.2 halves with trims etc.) and discover a vario with physid of 00 that works, you can now see vario values.

Now if you configure one of the widgets on the new screen to UNI-Rx Statistics 1.2 (this even works with the rx remaining connected) then you suddenly stop getting vario data. If you configure the widget back to --- then you do not suddenly start getting the vario data, however if you turn off the rx and turn it back on, then you do get the vario data again.

I believe this widget is one here https://github.com/strgaltdel/Ethos-Uni-Receiver which I notice has @strgaltdel Udo's finger prints on it ;) although that may just be a case of him copying to github. Udo, I don't know if you have a vario with default physid of 00 and are able to recreate?

Why am I using Uni firmware? Because I'm transitioning all my (too many) models (mostly XnR rx) from X10 opentx to X20S Ethos and don't want to find I have the wrong tx for the model, Uni allows me to easily swap between tx.

I don't believe that a widget should stop telemetry working for sensors with physid 00. By their nature, things like widgets and lua scripts are possibly going to be less robust than Ethos so even if it is doing something incorrectly (and I'm not saying it is), Ethos should be protected from that. I knew I tried to avoid widgets and lua scripts for a good reason!!

I suspect there is more going on here. Given the initial erratic nature of the problem I question if the problem could be related to the contents of the uni rx which data would have been displayed? Having spent too long looking at .bin files and trying to 'decode' them, I can't help wonder if the problem could partly be that the physid is 00 which Ethos is misinterpreting as meaning that there is nothing for this segment when in reality it's the data. Changing another sensor to physid 00 would possible enable this to be tested.

The above also possibly explains why more haven't been complaining of this, how many people are using Uni firmware stats with a vario. But if a widget can interfere with telemetry, what else can they interfere with? Today Uni firmware widget, tomorrow another widget.

Thanks

bsongis-frsky commented 5 months ago

I have just warned the RF engineer that you don't use his firmware. I think that this information is very important and should be said from the beginning.

Jedsters commented 5 months ago

As mentioned above, I was using S8R which doesn't have Uni firmware available for it so is using stock FrSky firmware. The initial vario.zip and play4.zip files attached also do not include Uni widget but still caused the problem. It is just that the Uni widget appears to recreate the problem reliably, so hopefully can be used to locate the source of the problem.

bsongis-frsky commented 5 months ago

Does the UNI widget sets the device as IDLE once it has finished?

strgaltdel commented 5 months ago

“Idle” ... there was something when I was “struggling” during my 1st ethos - lua steps https://github.com/FrSkyRC/ETHOS-Feedback-Community/issues/1621

@jedster: So I understand this correctly:

Which is your first mentioned vario, even frsky ?

My proposal:

Do you have the same Problems, even if the vario is the only sensor ?

How did you test the X10 / otx environment:

Which ethos revision ?

Jedsters commented 5 months ago

Udo, as Bertrand will hopefully attest, whenever I report an issue, where possible I give details on how to recreate it starting with creating a basic model (invariably a glider and just letting all options default other than giving it a name).

I notice Mike Blandford lives in Poole (I know it well, I lived there for 20+ yrs) and it is only 25miles from where I am now (45mins drive). If necessary I could possibly meet him to try to demonstrate etc. if needed.

I worked in software for 30+ yrs and know how difficult it is to diagnose erratic problems, so I've tried to do as much as I can to recreate it, but have yet to find a 100% reliable way to recreate, the Uni widget is simply the closest I've got. There is more to it than this.

Bertrand, in the past you gave me a modified version of Ethos with tracing of telemetry which didn't help you, I think the problem is internal rather than comms, do you perhaps have a version of Ethos with full on tracing going to a log file I can use? Hopefully with time stamps so I can edit out everything for you, other than when I can provoke the problem.

For info, I've tested 2 normal varios, 2 ADV varios, 2 other sensors (GPS, FLVSS), 3 Rx. Assorted cables between the sensors etc.. I only have one X20S! There is no common theme in the hardware and the varios etc. work with X10 / opentx.

Thanks guys.

Jedsters commented 5 months ago

Makes little odds, but since Udo mentioned it, the R10 PRO isn't currently detecting the ADV VARI as S.Port or FBUS (no Uni widget, basic model).

strgaltdel commented 5 months ago

I do hope your tests situation would not be to let run the uni-statistics script against a "standard" FrSky firmware ? It calls specific data, specialized on Uni receivers, dont know what happens in case these requests are done against a standard firmware ?

i searched the complete UNI-Beta test thread, nothing what would point into this issue, but an interesting note from reto & mike according to an other "unreliable telemetry data issue" when oXs seemed to flood the bus

"The main problem is the openXsensor is sending new data too often and the over the air link just cannot keep up. This results in the telemetry packet FIFO in the Rx filling up. Once it is full, any attempt to add to it fails until a packet gets sent to the Tx. ... Mike"

All my Vario sensors are running on PhyID 00 so this should not make the root cause, i requested Dirk Weiler to crosscheck this on his otx script

An interesting “finding” in the beta thread:

This otx script should allow the user to change AppID & data/refresh rate, maybe worth a test?

Sensor_Config_Frsky-mster.zip

All in all, I would find it VERY useful if this problem could be reproduced so that we can say with certainty that it is a systematic error. So I would wait for Andreas' reply to see if he finds time to cross-check with identical HW (Tx & Rx).

again:

the more i'm thinking about the more i'm wondering The last 48h we had discussions in german forum because a user got very low RSSI's in case he plugged an UNISENSE into SPort, he had sort of "crude" cabling , we were wondering about ground level shifting and some EMC problems, at last it was fixed by a receiver firmware upd (TD R10)

strgaltdel commented 5 months ago

the more i'm thinking about:

the "only" thing which stays with the problem is your x20 tx

did you ever did an update on your rf module, do you have the latest? sure you are using eu fw?

will wait for some infos from you

Andreas has a lot of workload, maybe he will send me a vario so i can try to reproduce the issue on uni fw side

Jedsters commented 5 months ago

Using X10 everything is ok Problems using uni f/w and Frsky f/w, it makes no difference Problems using access Problems using different varios

The only common is indeed the X20S / Ethos code.

I very much don't like that this is so erratic, it's almost like it is a time based problem!! It's also not lost on me that 00 is a 'special' number so possibly wasn't the best choice for a physical id, but there's not much we can do about that. That is assuming it is relevant - and as mentioned, I'm not 100% certain about that.

Yes, the X20S is mostly up to date (having spent a long time checking 1.5.6 so wasn't in a hurry to upgrade to 1.5.7, if I keep forever updating for no good reason (there was nothing in 1.5.7 which I felt I needed urgently) and having to recheck I'll get even less flying done than I am now.

image

I assume the 1.5.4 SD card reference is normal for 1.5.6 - I used suite to upgrade to 1.5.6 so it should have taken care of everything for me. I don't believe I ever installed 1.5.4, I went from 1.5.2 to 1.5.6 IIRC.

Partially for my sanity and also to demonstrate. See this video <EDIT large dropbox video deleted, as per Udo's comment below it showed that when I created a new model the model had Comp Mode set on in Telemetry when it should not have been on. Bertrand addresses this bug below> I hope you'll believe me when I say I'm using the same S8R (so that's stock firmware), ADV Vari, cable (and battery) all the time, that's it, nothing else connected. You can't quite see me binding (that's what the cocktail stick is doing), powering on and off, although the display on the screen and sound pretty much gives that away.

You can see me create a new basic model on X10 with opentx and bind it and that the telemetry shows the vario all working. I then switch to the X20S, create a new trivial model, bind it but the only telemetry discovered is that for the rx and not the vario. I've not touched the rx other than power on / off and bind it - the s.port cable and vario remains in place all the time. I struggle to believe I'm doing anything wrong, but would be happy if someone points out I'm doing something dumb which resolves the problem.

Thanks for the script, I'll have a look at that. If I can bypass the problem that would be good for me, however I don't think that would be a fix to the problem. I don't believe that using genuine products all from FrSky with their supplied settings should result in something not working. Although I think I'd want confirmation from Bertrand that he's happy for me to use this script as an aid to PD before I use it. He wasn't happy when he thought I was using Uni firmware on the rx, I don't want the same for sensors (I know it's not firmware).

Thanks

strgaltdel commented 5 months ago

jeddy, regarding your video hmmm:

what does the field entry: "competition mode (rssi and battery only)" look to you !

Jedsters commented 5 months ago

Good spot, at some point I've obviously accidentally hit the wrong button instead of discover and not noticed it! I need to do some retesting. I don't believe this explains the problem however as at times I have had problems with the vario while GPS / FLVSS are working, but certainly the most recent part of my testing is flawed! Thanks

Jedsters commented 5 months ago

But there is another interesting observation. At what point during the video do I select Competition Mode? As best I can see I don't! It appears that creating a new model results in this. That certainly didn't use to be the case. See around 3:30 when I first select the telemetry screen. Surely this isn't a transmitter setting which can be changed from every model? That could partly explain it if I have at some point selected it and even creating new models wouldn't reset it. I've not been looking out for this so it would mean I need to retest a lot of things if this is the case?

Jedsters commented 5 months ago

Another observation. I have done quite a bit of comparing of model.bin files. I understand that the header differs (different file names, length etc.) and I've noticed differences towards the end where I was testing telemetry etc. which were obviously telemetry related. However, I've also noticed a difference around byte x'32' (depending on model name length), I don't know if this could contain a flag for Competition mode etc..? I'd be interested to know if this is the case as this could help further testing.

Jedsters commented 5 months ago

e.g. I notice that in my initial model.bin files, Play3 has a value of x'05' at x'2B' while Play has a value of '0F' at corresponding x'2A' Is this significant?

Jedsters commented 5 months ago

To answer my own point from a few above, it appears that if you have Competition Mode selected when you create a model then the model you create will also have it on and vice versa. That will explain part of the problem with my testing. But again, there is more going on as the vario wasn't working when it was present in telemetry and if it was just a matter of competition mode having been selected then the vario wouldn't even be in telemetry. However, I think Udo is on to something...

strgaltdel commented 5 months ago

i want to be sure that i dont give tasks to other people in case there is no "specific" issue after the "competition mode"realizations, we should proof again if both, uni fw & frsky, shows the same symptoms. i want to rule out "mixed test scenarios", so that others should be able to reproduce the issue in case there is a systematic failure if possible for you, we should focus on two receivers

i would propose following scenario a) built a new, "empty" model template, this is the master template and clone this for all your tests b) rf setting accst/d16 (uni receiver) or access (frsky like r10pro) ; model id 21, to have the same over all testings c) no widgets d) only adv vario connected to sport e) on uni receiver: ensure that sport (not fbus) is set by using the "uniset" script d) ensure a stable (bec/battery) power supply on rx e) no servos, "lean scenario"

now check if vario can reliable be detected after bind or not

please report asap, if problem stays. in case vario is not detected or does not deliver data, please check led status: is it really blinking "slow" ? adv varios should autodetect sport. i want to rule out false detection

depending on result, we can plan further steps

regards udo

bsongis-frsky commented 5 months ago

it appears that if you have Competition Mode selected when you create a model then the model you create will also have it on and vice versa

Bug. This will be fixed in 1.5.8

Jedsters commented 5 months ago

Bertrand (and Udo, please see below, but it would be useful if you read this too).

Thanks for confirming the Competition Mode inheriting the current model comp mode status bug.

I believe there is a similar bug for Bluetooth too. That also appears to inherit the status of the currently selected model rather than creating a model with a consistent status (I can't say I care whether it's On or Off, it should just be consistent - I guess if you pushed me I'd say Off, but that's only because I don't use it and gets it out of my way).

The question is what else is behaving the same? Is there a byte of 8 flags being incorrectly copied from the current model rather than all being set to 'off'? However, a quick bit of testing suggests that rather than being flags in a byte, each of the above are bytes with a value of 00 (off) or 01 (on) towards the end of the model.bin. So it may not be such an easy case of checking one byte, so much as all similar bytes.

Here is another bug in this area. Select a model which has comp mode off (I say to do this simply because of the above bug and feel it safer to start here), now create a new basic model. If you look at telemetry you'll see that comp mode is off. All good so far. Now setup the RF etc. and discover telemetry with a sensor attached to the rx, again all good, it discovers the rx and vario in my case. Now select Comp Mode (as I have done accidentally from time to time while testing - fat fingers), except when I did this in my testing it was by accident, so now at the confirmation message 'All the sensors will be removed. Are you sure you want to continue?' select No because you don't want to delete all your lovely sensors and muck up all the LS/SF/ Widgets which reference them, this was just fat fingers. However if you take the time to check (which I didn't, why would I?) you'll notice that Comp Mode still displays as On and yet telemetry is still updating! How can that be? Selecting another model and then this one again or turning off / on leaves this in the same situation - Comp mode is on and my vario is quite happily updating. Something is very wrong here.

The last bug above indicates that the Comp Mode switch / byte is not what is controlling whether telemetry is active or not! So what is controlling telemetry? Once we know what really is controlling telemetry then we may be able to explain some of the erratic behaviour I keep reporting.

Here is another situation which may explain my problems. Create a new model again from a model with Comp Mode off, setup the RF. Go to telemetry, no select Comp mode but again select No - fat fingers again. Now select Discover sensors - guess what, I'm only getting the rx. I didn't even notice that Comp mode was still on, why would it be, I just said I don't want it!! Combine this problem with cloning of such models or creating other models while this was the situation and all bets are off as to what I spent days testing last week! I'm fairly certain it wasn't what I thought I was testing.

However there are still possibly other unresolved / unexplained problems here...

Going back to the video posted above https://www.dropbox.com/scl/fi/23sz499m6fcibiwhc8uho/VID_20240504_133648.mp4?rlkey=mx1dnszhj71e09qfkvidsg0ts&e=1&st=v8d735y1&dl=0 you can see from this that I had telemetry working until I added the Uni widget. You can see that when I returned to the telemetry screen that Comp mode was still set on. At one point I thought that I could do similar with a Text Widget but this wasn't so consistent, I do not believe Uni widget is the cause of the problem. It's not clear to me if the above bugs explain this or not, I guess it is quite likely that adding a widget which goes towards the end of the model.bin could turn on the byte which is really being used to control telemetry which is also in a similar area of the model.bin.

Finally given that there is a similar problem with Bluetooth at the top, is there a similar situation where BT may be on when it should be off and vice versa? Personally I don't use BT so I don't care and I'm not paid enough (well anything) to test that. LOL

One final trivial problem - if you delete all sensors then all the area at the bottom of the Telemetry screen remains, surely this blank area should be deleted.

Udo, Please see above. I certainly wouldn't drag anyone else into this, I can't see how the above can be explained by anything other than bug(s) in Ethos. Given that we don't know what is really controlling whether telemetry is on or not I really don't see that there is any point in testing further, we can't actually know whether the tests are valid as the Comp Mode switch certainly doesn't tell us!

I don't think there is any point in me testing this further (unless I think of any more tests which may give clues as to what is going on, in which case I'll report) until I have the fixes for all the above problems. It appears that my days of testing this week were largely wasted, I need to catch up with other stuff now.

Thanks guys.

Jedsters commented 5 months ago

First here is a video demonstrating one of the problems above where the Comp Mode switch doesn't work correctly.

https://www.dropbox.com/scl/fi/bfscwzd2os8wu0br1yj3x/VID_20240505_135411.mp4?rlkey=a505zxvh09da06yopqujvxk1g&e=1&st=astq53w0&dl=0

Secondly, Bertrand, given how much time I've spent on this problem including having to totally recreate an 8kb model, if your fix doesn't automatically fix my existing template and models I've created using it, would you be so kind as to either explain what I need to do to fix them or advise which bytes I need to change in the model.bin to fix them please? I don't really want to have to recreate my template again, not least due to the risk of me introducing bugs into my own template.

Finally, Udo, Very many thanks for another pair of eyes! There is no way that I'd have spotted that Comp Mode was defaulting to on, I wasn't even looking at it. I certainly never wanted it and when I accidentally did select it I said No so it didn't occur to me to check that I was actually getting No! You know how it goes with things like this, after a while you're so busy looking at where you believe the problem is that you fail to look at the obvious. It possibly doesn't help that I never use Comp Mode so the consequences aren't something I normally see. I suspect if I used it then it may have occurred to me that something could be wrong in this area. Much appreciated!!

Thanks guys

strgaltdel commented 5 months ago

In the end, I am glad that we have found the cause (and that it's not related to frsky or uni FW, or one of my scripts)

but what we can learn, imho:

there is the term "If it looks like a duck, swims like a duck, and quacks like a duck..."

... and this vario failure never looked like a rf FW/ s.port -duck but it did cost some time & text to recognize this next time we should do better (-;

so this problem has nothing in common with the topic written in the headline

maybe it would be a good idea to close this issue, and when additional "competition switch" related problems were found, to open a new one

regards Udo

Jedsters commented 5 months ago

Hi Udo, I don't think I really want to close this yet as I don't feel we've found all the problems. I've tested the model I was flying last week when I discovered I didn't have any vario and I can confirm that Comp Mode is not on (or at least doesn't appear to be on) and yet it is not detecting the vario data. I've tried deleting the vario and VSpeed and rediscovering them but even with Comp mode off, I can not rediscover the vario or VSpeed. However, I am getting GPS data, which suggests that Comp Mode is really not on. This is therefore exactly as per the title and I'm not sure any of the above really explains this. It may be that the fix which corrects the Comp Mode switch fixes this, or it may be that it doesn't. I can't know yet. There are multiple problems here, what we don't know yet is how many bugs these stem from. This one looks like a cow, swims like a duck and oinks like a pig! I'm struggling to think what I could have done better - whether noticing that Comp Mode was sometimes on would have helped I'm not sure, maybe it would have, maybe it would have made no difference. Thanks again.

Jedsters commented 5 months ago

Guys, hopefully a bit of good news. I believe I can pretty reliably recreate the main problem I'm seeing (sorry Udo, the only way I've found to do so is to use your Uni widget although again, I'm not saying it is the cause of the problem, but rather a good way to provoke it. If it is causing the problem then Ethos isn't stopping it. It may well be other widgets etc. could cause the problem too).

Scenario 1: Create a new basic model (from a model which has Comp Mode off) Setup the RF Connect an Rx (S8R with FrSky firmware used) which has ADV VARI (physid 00), GPS sensor and FLVSS (unattached). The GPS and FLVSS sensors are more to keep track on what telemetry is going on than actually being relevant to the problem. Discover sensors - all sensors are discovered and appear to work normally. Add a new screen Add the Uni widget to the new screen and telemetry is immediately lost. Comparing the difference in the model.bin before adding the Uni widget and immediately after reveals the following - ignoring the first 16 bytes (model name, file length etc.) the only differences are:

image

you can see the end of the telemetry definitions and when the Uni widget is added we get an extra section in the model.bin for the updated model on the right around where it says unow02

I then deleted the Uni widget (changed to ---) but still there was no vario data so I did a delete all sensors and rediscovered. The problem has now become locked into the template / model and any clones thereof. (I'm not sure how reproducible this last part is, I've done it more than once though). The question is what has changed to lock the problem in, even without the Uni widget.

This time comparing the file with the Uni widget with the file after I'd removed the widget and rediscovered sensors and was still missing the vario we get

image

it appears the telemetry has been discovered in a slightly different order which I'm sure isn't a problem, but still failing to rediscover the vario is. You can see the Uni widget definition has been removed though.

However, there are certainly a number of more unknowns and unexplained things going on in this area. Some things I'm doing are not reliably recreatable, maybe I'm doing something very slightly different, who knows. However I do question if the above was fixed if that would prevent all of these unknowns from manifesting themselves.

Bertrand, if you can spot anything suspicious in the model.bin and would like me to test changing the odd byte value or 3, just shout, I can try this and see if it makes the vario usable again. That may help you locate what is going wrong and how to fix it?

Thanks

strgaltdel commented 5 months ago

All i can say is: the "uni stats widget" was never intended to let it "run against" FrSky FW. Basically, it polls "Uni FW data" with AppID "0x0C20" these polled statistic Values are DataItems , according to M.Blandforts firmware, 0x00FF .. 0x0BFF

Again, as an explanation: You are invoking S.port “instructions” against a device that was never intended to receive them, therefore the result cannot be predicted.

it' like a sort of hack, that may cause failures that would never occur under regular operations

In case it can help to find a failure, OK, but i never would say that inproper functionality of a "FrSky FW" receiver after using this script is something like a "smoking gun"

that the rx will be in trouble using the widget won't surprise me what happens after Rx stops sending telemetry, and deleting the widget, AND POWER CYCLE RX ? will telemetry come back?

Jedsters commented 5 months ago

Sorry, are you saying that running the widget with non Uni firmware could cause problems for the rx?
I have to be honest, I assumed it was a one way street and it was simply displaying data it was getting from the rx. I'd considered that it may get data that may not be appropriate but would like to think that Ethos would prevent it mucking up a model definition.

Should I worry about any of the non Uni f/w Rx I've used this with (mostly SxR) and rewrite the firmware for them?

Jedsters commented 5 months ago

In light of Udo's comment above I'm going to do as suggested and split the obvious Ethos bugs into their own issues but leave this open for now until I understand more fully the consequences of the comment.

strgaltdel commented 5 months ago

"that running the widget with non Uni firmware could cause problems for the rx?"

i dont know because i dont know internals of frsky RX Firmware and why i should?... Getting the statistics out of an Uni RX is not as getting classic sport telemetry sensors. lets say you address the rx and request specific registers, because you (or mike blandfort) knows what this does mean for the rx.

i dont know what happens to a frsky fw rx, maybe he will ignore these requests, maybe he "interpretes" the data aquise "command" right but struggles with one of the "arguments" / DataIDs because he doesnt support these

simple rule: no uni receiver, no uni widget.

Jedsters commented 5 months ago

Fair comment! I think I'll just delete the widget from my tx. I knew there was a reason I tried to avoid lua and widgets. Thanks again for all your help and input.

bsongis-frsky commented 5 months ago

If you don't call sensor:idle() at the end of the script, the sensor will remain silent, it just wait for some settings READ / WRITE.

strgaltdel commented 5 months ago

Thanks for the hint !

Jedsters commented 5 months ago

Does that have any implication for me, my rx or the problem?

Jedsters commented 5 months ago

I've just tested an RX8R with Uni firmware and UniStat and assorted sensors including ADV VARI on physid channel 00 and everything works as expected. This does therefore suggest that the problem is caused by using the UniStat script with a non-Uni firmware rx. To be a little bit fair to me, I can't see anywhere in the Uni Firmware details where it says not to use it with models which do not have Uni firmware and I can also foresee people changing rx and forgetting to delete UniStat widget even if they do know it shouldn't be used with the new rx. Udo, unless I'm missing it, may I suggest that suitable warning is added somewhere in the Uni firmware instructions to try to avoid similar problems in future and is it possible to adjust the UniStat script so that it can detect a non Uni firmware rx in such a way as it won't cause any problems if it is done?

Other than that I'm happy to close this, unless either of you has anything to add, as the bugs discovered in trying to resolve this have now been recorded in other issues.

Apologies for something which was partly my fault and very many thanks, as ever.