ERSKY9X Coding

[ozphoenix]

Attached file is 20 secs of EID1 then added DID11 for about 20 secs, then removed DID11 and left EID1 for about 20 secs, then removed power from S8R -- all other parameters remained the same as before. The file is actually a .raw, but renamed as a .rar for posting purposes.

You may find you need to wait longer than 5 seconds after connecting a sensor before data is sent.
At the end of a logging test, wait a few more seconds, I buffer 256 bytes of raw data before writing it to the file, so you may "lose" up to 256 bytes when you stop logging.

The format is the same:
7E
Physical ID
10
xx xx Application ID
xx xx xx xx data
xx CRC

Frames starting 7E 98 10 xx F1 are from the XJT and have RSSI or SWR or RxV in them.

Mike

[ozphoenix]

Mike,
Possible first little bit of enlightenment (for me) - is it possible that the FrSky program reports PHYSICAL device ID -- that is, the first, the second, the third, … etc and NOT LOGICAL device ID???

Clue 1. The FrSky program page shows 'PhyID' as a label, not just 'ID' or 'LogID'.
Clue 2. You cannot select a '0' in this box, only '1' and above.
Clue 3: I now have a variometer connected to it and then to my QX7 module bay pins -- the FrSky program says it is PhyID '1', but the QX7 says ID 0 AppID 0100 (then 0110).
Clue 4: I now have a FCS40 current sense device connected to it and then to my QX7 module bay pins -- the FrSky program says it is PhyID '3', but the QX7 says ID 2 AppID 0200 (then 0210).
Clue 5: yesterday, the 9XRPro and the QX7 consistently showed an ID number 1 less than the FrSky program for MLVSS devices.

Seems fairly conclusive to me.
If this is the case, it would answer a couple of my questions and allow me to be more accurate with my device setup for debug, etc.

EDIT NOTE: AAARGH! Just read your 'edit' note at the bottom of the post where you gave me the program! Ok, so we're on the same page - 'physical' in the program, 'logical' on radios. ))

[ozphoenix]

Ok, having clarified the correct number for ID (I think) here is a file with 3 devices (with checked and verified ID and PhyID) connected: 1x MLVSS ID1 (Phy2) with 3S battery, 1x MLVSS ID11 (Phy12) with 4S battery, 1x FCS40 ID2 (Phy3) in line with 3S battery to ESC supplying S8R Rx.
The configuration was powered up already connected to the Rx and left on for about 15-20 seconds. No changes were made to the configuration during that time. Again, a .raw file labelled as .rar
regards,
ozphoenix

[ozphoenix]

Actually, it wouldn't be PHYSICAL ID unless you had that many actual devices, would it - so, they've labelled it incorrectly in the program and it does (as now known) (incorrectly) display ID+1 instead of (correctly) ID.
To remain clear, I'll ONLY refer to (correct) ID from here, not FrSky's PhyID - I'll just have to remember to do the arithmetic correctly any time I'm touching the STK+FrSky program combination, I guess.

Mike,
Possible first little bit of enlightenment (for me) - is it possible that the FrSky program reports PHYSICAL device ID -- that is, the first, the second, the third, … etc and NOT LOGICAL device ID???

Clue 1. The FrSky program page shows 'PhyID' as a label, not just 'ID' or 'LogID'.
Clue 2. You cannot select a '0' in this box, only '1' and above.
Clue 3: I now have a variometer connected to it and then to my QX7 module bay pins -- the FrSky program says it is PhyID '1', but the QX7 says ID 0 AppID 0100 (then 0110).
Clue 4: I now have a FCS40 current sense device connected to it and then to my QX7 module bay pins -- the FrSky program says it is PhyID '3', but the QX7 says ID 2 AppID 0200 (then 0210).
Clue 5: yesterday, the 9XRPro and the QX7 consistently showed an ID number 1 less than the FrSky program for MLVSS devices.

Seems fairly conclusive to me.
If this is the case, it would answer a couple of my questions and allow me to be more accurate with my device setup for debug, etc.

EDIT NOTE: AAARGH! Just read your 'edit' note at the bottom of the post where you gave me the program! Ok, so we're on the same page - 'physical' in the program, 'logical' on radios. ))

[ozphoenix]

Just for completeness, here is a file with 1x Vario ID0 added in to 1x MLVSS ID1 with 3S battery, 1x MLVSS ID11 with 4S battery, 1x FCS40 ID2 in line with 3S battery to ESC supplying S8R Rx, total of 4x connected devices.
The configuration was powered up already connected to the Rx and left on for about 15 seconds. No changes were made to the configuration during that time. Again, a .raw file labelled as .rar
regards,
ozphoenix

[ozphoenix]

Sorry, MLVSS ID1 had the battery balance lead disconnected in this '1439xx' file - will reconnect now and post a new file in a few moments.

Just for completeness, here is a file with 1x Vario ID0 added in to 1x MLVSS ID1 with 3S battery, 1x MLVSS ID11 with 4S battery, 1x FCS40 ID2 in line with 3S battery to ESC supplying S8R Rx, total of 4x connected devices.
The configuration was powered up already connected to the Rx and left on for about 15 seconds. No changes were made to the configuration during that time. Again, a .raw file labelled as .rar
regards,
ozphoenix

[ozphoenix]

Corrected log file, replaces '1439xx' with battery now connected to MLVSS ID1.

Sorry, MLVSS ID1 had the battery balance lead disconnected in this '1439xx' file - will reconnect now and post a new file in a few moments.

Just for completeness, here is a file with 1x Vario ID0 added in to 1x MLVSS ID1 with 3S battery, 1x MLVSS ID11 with 4S battery, 1x FCS40 ID2 in line with 3S battery to ESC supplying S8R Rx, total of 4x connected devices.
The configuration was powered up already connected to the Rx and left on for about 15 seconds. No changes were made to the configuration during that time. Again, a .raw file labelled as .rar
regards,
ozphoenix

[ozphoenix]

HEY! Fully loaded up like this (EDIT: multiple MLVSS but also additional SPort devices, as noted below), I see all cells on both MLVSS and the reporting is correct on the Telemetry screens! I will remove one device at a time and see what/when changes occur - wait a few minutes, please.

Hmm, if I take off the Vario (last physical device plugged into the chain and immediately after the last MLVSS ID11), I lose MLVSS ID1 (first physical device in the chain) ticks and data!
If I put the vario back on the end of the chain, I get the values for MLVSS ID1 coming back in properly and as expected!
If I have the FCS40 as the last device (and not the vario), I get a similar result.
If I remove the FCS40 (second last physical device plugged into the chain), I lose MLVSS ID1 ticks and data!
If I put the FCS40 back on the end of the chain, I get the values for MLVSS ID1 coming back in properly and as expected!
During these times, the readings on MLVSS ID11 (second MLVSS - physically the third last -- or, alternatively, the second from the beginning -- device on the chain) continue to read correctly.

Confirmed and checked - removing the vario stops not only the vario feed, but stops the MLVSS ID1 feed, if there is no other device on the chain after the second MLVSS (ID11). Returning the vario connection restarts the MLVSS ID1 feed correctly. Adding two devices after the MLVSS ID11 only 'loses' MLVSS ID1 data if both devices are removed - removing one device does not disturb MLVSS ID1. That is, removing BOTH devices (FCS40 and vario) from after the second MLVSS stops the correct reporting of MLVSS ID1 (the first physical device in the chain).

Attached is a file of the fully configured system, with two batteries connected. Configuration is 1x Vario ID0 added in to 1x MLVSS ID1 with 3S battery, 1x MLVSS ID11 with 4S battery, 1x FCS40 ID2 in line with 3S battery to ESC supplying S8R Rx, total of 4x connected devices. Physically, MLVSS ID1 is first in the daisy-chain after the Rx, then MLVSS ID11, then FCS40 ID2 and then vario ID0 as last physical device.

The configuration was powered up already connected to the Rx and left on for about 15 seconds of logging. Then I removed the vario for 15 seconds, returned it for 15 seconds, then I removed the FCS40 (only, but had to reconnect the vario to the chain) for 15 seconds, then returned it for 15 seconds (first had to remove the vario for an instant to put it back into the chain in its original place), then I removed BOTH the vario and the FCS40 for 15 seconds. Then, returned both devices to be back at the original configuration again. At no time were either of the MLVSS devices removed from the chain or disturbed in any way.

Hmm, I think you will need two MLVSS units to get closer on this one, Mike

Again, a .raw file labelled as .rar

ozphoenix

[ozphoenix]

Mike,
Please correct me if I am wrong - some observations from my inexperienced eyes and the last logfile I sent (-153007xxxx):
MLVSS2 ID11 is being reported as ID byte=E9h - correct? which is 1110 1001, which is not 0Bh (0000 1011), even if you account for some bits in the upper 3 bits active - correct?
40/42 Byte is sometimes 40, sometimes 42 (as you mentioned earlier) - correct?
MLVSS1 ID1 in the very first part of the file where everything is first connected, is being reported as A1 (as you mentioned earlier) - correct?
Am still looking at the file to try to see what happens when I remove the last two devices from the chain.

[ozphoenix]

Mike,,
Not sure if this is helpful, but might be. I created another, shorter, logfile of just one instance of disconnect and reconnect of two devices (Vario and FCS40) at the same time. I believe that the following data are the readings of the instant of disconnect, from the last good reading of the MLVSS ID11, through the actual disconnect and then the instant just after:
002384 7E E9 10 00 03 42 83 77 78 37
002400 7E 0D 7E 8E 7E 2F 7E D0 7E E9 10 00 03 40 75 57
002416 77 68 7E 71 7E F2 7E 53 7E 34 7E 95 7E 16 7E B7
002432 7E 39 7E BA 7E 1B 7E 83 7E E4 7E 45 7E C6 7E 98
002448 10 05 F1 01 26 07 00 CA 7E 98 10 01 F1 63 00 00
002464 00 99 7E 98 10 04 F1 59 00 00 00 A0 7E 67 7E 48
002480 7E 6A 7E CB 7E AC 7E 0D 7E 8E 7E 2F 7E D0 7E 71
002496 7E F2 7E 53 7E 34 7E 95 7E 16 7E B7 7E 39 7E BA
002512 7E 1B 7E 00 7E A1 7E 22 7E 83 7E E4 7E 45 7E C6
002528 7E 67 7E 48 7E E9 7E 6A 7E CB 7E AC 7E 0D 7E 8E
002544 7E 98 10 05 F1 01 26 07 00 CA 7E 98 10 01 F1 5E
002560 00 00 00 9E 7E 98 10 04 F1 59 00 00 00 A0 7E 2F
002576 7E D0 7E 71 7E F2 7E 53 7E 34 7E 95 7E 16 7E B7
002592 7E 39 7E BA 7E 1B 7E 00 7E A1 7E 22 7E 83 7E E4
002608 7E 45 7E C6 7E 67 7E 48 7E E9 7E 6A 7E CB 7E AC
002624 7E 0D 7E 8E 7E 2F 7E D0 7E 71 7E F2 7E 53 7E 34
002640 7E 95 7E 98 10 05 F1 01 26 07 00 CA 7E 98 10 01
002656 F1 5D 00 00 00 9F 7E 98 10 04 F1 59 00 00 00 A0
002672 7E 16 7E B7 7E 39 7E BA 7E 1B 7E 00 7E A1 7E 22
002688 7E 83 7E E4 7E 45 7E C6 7E 67 7E 48 7E E9 7E 6A
002704 7E CB 7E AC 7E 0D 7E 8E 7E 2F 7E D0 7E 71 7E F2
002720 7E 53 7E E9 10 00 03 42 83 37 78 77 7E 34 7E 95
002736 7E 16 7E B7 7E 39 7E E9 10 00 03 40 71 A7 77 1C
002752 7E BA 7E 98 10 05 F1 01 26 07 00 CA 7E 98 10 01
002768 F1 61 00 00 00 9B

The following data is the instant just before, through and after the reconnect and through the first couple of good MLVSS ID1 reads after that:
004848 7E 98 10 01 F1 60
004864 00 00 00 9C 7E 98 10 04 F1 59 00 00 00 A0 7E E4
004880 7E 45 7E E9 10 00 03 42 83 B7 78 F6 7E C6 7E 67
004896 7E 48 7E 6A 7E CB 7E AC 7E 0D 7E 8E 7E 2F 7E D0
004912 7E 71 7E E9 10 00 03 40 75 A7 77 18 7E F2 7E 53
004928 7E 34 7E 95 7E 16 7E E9 10 00 03 42 87 37 78 73
004944 7E B7 7E 39 7E BA 7E 1B 7E 00 7E A1 7E 22 7E 83
004960 7E E4 7E 45 7E C6 7E E9 10 00 03 40 71 A7 77 1C
004976 7E 67 7E 98 10 05 F1 01 24 06 00 CD 7E 98 10 01
004992 F1 5E 00 00 00 9E 7E 98 10 04 F1 59 00 00 00 A0
005008 7E 48 7E E9 10 00 03 42 87 37 78 73 7E 6A 7E CB
005024 7E AC 7E 0D 7E 8E 7E 2F 7E D0 7E 71 7E F2 7E 53
005040 7E 34 7E E9 10 00 03 40 75 57 77 68 7E 95 7E 16
005056 7E B7 7E 39 7E BA 7E E9 10 00 03 42 83 77 78 37
005072 7E 1B 7E 00 7E A1 7E 22 7E 83 7E E4 7E 45 7E C6
005088 7E 67 7E 48 7E 6A 7E E9 10 00 03 40 75 57 77 68
005104 7E CB 7E 98 10 05 F1 01 23 06 00 CE 7E 98 10 01
005120 F1 5F 00 00 00 9D 7E 98 10 04 F1 59 00 00 00 A0
005136 7E AC 7E E9 10 00 03 42 87 77 78 33 7E 0D 7E 8E
005152 7E 2F 7E D0 7E 71 7E F2 7E 53 7E 34 7E 95 7E 16
005168 7E B7 7E E9 10 00 03 40 75 A7 77 18 7E 39 7E BA
005184 7E 1B 7E 00 7E A1 7E E9 10 00 03 42 7D 5E 77 78
005200 3C 7E 22 7E 83 7E E4 7E 45 7E C6 7E 67 7E 48 7E
005216 6A 7E CB 7E AC 7E 0D 7E 8E 7E 2F 7E D0 7E 98 10
005232 05 F1 01 26 07 00 CA 7E 98 10 01 F1 5F 00 00 00
005248 9D 7E 98 10 04 F1 59 00 00 00 A0 7E 71 7E F2 7E
005264 53 7E 34 7E 95 7E 16 7E B7 7E 39 7E BA 7E 1B 7E
005280 00 7E A1 7E 22 7E 83 7E E4 7E 45 7E C6 7E 67 7E
005296 48 7E E9 7E 6A 7E CB 7E AC 7E 0D 7E E9 10 00 03
005312 40 71 A7 77 1C 7E 8E 7E 2F 7E D0 7E 71 7E F2 7E
005328 E9 10 00 03 42 7D 5E 77 78 3C 7E 53 7E 34 7E 95
005344 7E 98 10 05 F1 01 26 07 00 CA 7E 98 10 01 F1 66
005360 00 00 00 96 7E 98 10 04 F1 59 00 00 00 A0 7E 16
005376 7E B7 7E 39 7E BA 7E 1B 7E 00 7E A1 7E 22 7E 83
005392 7E E4 7E 45 7E C6 7E 67 7E 48 7E 6A 7E E9 10 00
005408 03 40 75 57 77 68 7E CB 7E E9 10 00 03 42 83 B7
005424 78 F6 7E AC 7E 0D 7E 8E 7E 2F 7E D0 7E E9 10 00
005440 03 40 71 E7 77 DB 7E 71 7E F2 7E 53 7E 34 7E 95
005456 7E 22 10 00 02 00 00 00 00 ED 7E 22 10 10 02 67
005472 04 00 00 72 7E E9 10 00 03 42 83 77 78 37 7E 16
005488 7E 98 10 05 F1 01 26 07 00 CA 7E 98 10 01 F1 60
005504 00 00 00 9C 7E 98 10 04 F1 59 00 00 00 A0 7E B7
005520 7E 39 7E BA 7E E9 10 00 03 40 71 A7 77 1C 7E 1B
005536 7E 00 7E A1 7E 83 7E E4 7E 45 7E C6 7E 67 7E 48
005552 7E 6A 7E CB 7E AC 7E 0D 7E 8E 7E 2F 7E D0 7E 71
005568 7E F2 7E 53 7E 34 7E E9 10 00 03 42 83 B7 78 F6
005584 7E E9 10 00 03 40 75 57 77 68 7E 95 7E 16 7E B7
005600 7E 39 7E 22 10 10 02 67 04 00 00 72 7E 22 10 00
005616 02 00 00 00 00 ED 7E BA 7E 1B 7E 98 10 05 F1 01
005632 26 07 00 CA 7E 98 10 01 F1 5D 00 00 00 9F 7E 98
005648 10 04 F1 59 00 00 00 A0 7E E9 10 00 03 42 83 77
005664 78 37 7E E9 10 00 03 40 75 57 77 68 7E 00 7E A1
005680 7E 83 7E E4 7E 45 7E C6 7E 67 7E 48 7E E9 10 00
005696 03 42 83 37 78 77 7E 6A 7E CB 7E AC 7E 0D 7E 8E
005712 7E 2F 7E D0 7E 71 7E E9 10 00 03 40 71 E7 77 DB
005728 7E F2 7E 53 7E 34 7E 95 7E 16 7E B7 7E 39 7E BA
005744 7E 22 10 10 02 67 04 00 00 72 7E E9 10 00 03 42
005760 87 37 78 73 7E 1B 7E 00 7E A1 7E 83 7E E4 7E 98
005776 10 05 F1 01 26 07 00 CA 7E 98 10 01 F1 5C 00 00
005792 00 A0 7E 98 10 04 F1 59 00 00 00 A0 7E 00 10 00
005808 01 F1 41 00 00 BB 7E 00 10 10 01 76 FF FF FF 68
005824 7E 22 10 00 02 00 00 00 00 ED 7E 45 7E A1 10 00
005840 03 32 52 07 00 61 7E 00 10 00 01 F1 41 00 00 BB
005856 7E E9 10 00 03 40 71 A7 77 1C 7E 00 10 10 01 76
005872 FF FF FF 68 7E C6 7E E9 10 00 03 42 83 77 78 37
005888 7E 67 7E 48 7E 6A 7E CB 7E AC 7E 0D 7E 8E 7E A1
005904 10 00 03 30 4D 67 75 92

Please correct me if I'm wrong.

regards,
ozphoenix

[MikeB]

I'll look through the data later today.
0xE9 is ID 9, not ID 11.
The 40 value indicates 4 cells, this packet contains cells 0 and 1. The 42 value indicates 4 cells, this packet contains cells 2 and 3.

Mike

[ozphoenix]

0xE9 is ID 9, not ID 11.
(one of) my points, exactly - I'll look again at the device to validate the ID number. The re-appearance (and disappearance) of the correct data on a 'loaded' system is intriguing, nonetheless.

Otherwise, thanks, I look forward to your feedback - the clarifications confirm my (new) understanding of those points.

regards,
ozphoenix

I'll look through the data later today.
0xE9 is ID 9, not ID 11.
The 40 value indicates 4 cells, this packet contains cells 0 and 1. The 42 value indicates 4 cells, this packet contains cells 2 and 3.

Mike

[ozphoenix]

Mike,
More information that I hope is useful.
After you confirmed my suspicion that I was not going nuts and the MLVSS D ID11 was, in fact, set as ID9 and reporting as such, I got back to my desk and dug out my STK/FrSky Tool(s) and my QX7 again. Indeed, it showed as ID9 with the QX7 back module pins and it showed as PhyID 10 (therefore, SPort ID9) using the FrSky tool.
Now, no matter how many times I tried, with both the QX7 and with the STK/FrSky tool(s), to change MLVSS 'D' ID9 to ID11 -- and that update was reported as complete by both the QX7 and the STK/FrSky tool(s) -- it would not RETAIN that new number, always reverting to the original 'ID9' (or PhyID10) once power cycled --- EXCEPT --- once I connected the FCS40 and the Vario (but not the second MLVSS, in case it clouded things) -- both the QX7 and the STK/FrSky tool(s) were able to change the ID9 to a genuine ID11 .... AND IT STUCK.
Both QX7 and STK now report it as ID11, whether or not there are other devices in the chain or not.

However, this is only confirmation that there is a problem with having two MLVSS devices connected -- once I reconnected the two MLVSS units (ID1 and the now changed ID11) to the S8R, the same problem as before still exists for readings -- until I physically connect another SPort device - either Vario or FCS40 or both (it doesn't matter which or both) onto the end of the daisy-chain, the readings for MLVSS ID1 do not appear at the radio. Once I connect another device (or two) the readings for MLVSS ID1 immediately appear, as they should.

So, confirmation, but also maybe some additional information?

regards,
ozphoenix

[MikeB]

Could you try connecting the "other" devices first in the daisy chain, then the two MLVSS sensors at the end please?
This is to check if it is a hardware problem or a software problem.
The Rx polls all possible sensors in turn. However, once a sensor is found it is polled much more frequently. So if you have two sensors connected with IDs 1 and 11, the polling sequence is 1, 11, 0, 1, 11, 2, 1, 11, 3 etc. Adding more sensors will reduce the polling rate to known sensors.

I don't know if you have the PC software and hardware to capture the serial data on the Rx SPort signal. It is inverted serial at 57600 baud (0V is line mark, 5V is line space), so a standard serial adapter will connect directly.

Mike

[ozphoenix]

Now done.
When I put the FCS40 first in the chain, then MLVSS ID1, then MLVSS ID11, everything works as it should (all readings displayed correctly).
When I removed the FCS40 and installed the vario, everything works as it should (all readings displayed correctly).
When I add both the FCS40 AND the vario into the daisy-chain BEFORE the MLVSS ID1, everything works as it should (all readings displayed correctly).
As expected, when I remove both the FCS40 and the vario, the radio loses MLVSS ID1's readings.

Sadly, the last PC/laptop device that I owned which had a standard serial adapter in it died many years ago - all of my devices now have USB There is an extremely thin chance (but extremely) that I might have a working USB/serial converter lying in a box in a storage shed on the other side of my acreage, but that's not somewhere I'd go looking at night, especially on such a slim chance -- have seen many nice sized snakes in and around that shed and in the boxes there over the past few years However, the head office of our local electronics shop franchise has two different Windows 10-compatible DB9-serial-to-USB converters in their catalogue - our local shop is only a small countryside outlet and doesn't carry a lot of stock of such ageing and unusual devices, but I could contact them tomorrow (our time) and ask if they just happen to have one on their local shelf or, if not, how long to get one in -- I'm happy to get one if that would help you a great deal or if my delivery time is less than your delivery time for some local MLVSS devices.

ozphoenix

Could you try connecting the "other" devices first in the daisy chain, then the two MLVSS sensors at the end please?
This is to check if it is a hardware problem or a software problem.
The Rx polls all possible sensors in turn. However, once a sensor is found it is polled much more frequently. So if you have two sensors connected with IDs 1 and 11, the polling sequence is 1, 11, 0, 1, 11, 2, 1, 11, 3 etc. Adding more sensors will reduce the polling rate to known sensors.

I don't know if you have the PC software and hardware to capture the serial data on the Rx SPort signal. It is inverted serial at 57600 baud (0V is line mark, 5V is line space), so a standard serial adapter will connect directly.

Mike

[ozphoenix]

I'll look in the boxes in my shed tomorrow, but in daylight.
Attached are pictures of just two of the snakes I dealt with around my house a few weeks ago - I say 'just two' because I removed two and 'dealt with' three others (total 5) over a space of about 5 weeks recently. The large one shown in a night photo is non-venomous, but takes delight in crushing its 'kill' before consumption - it was approx. 8 feet (2.7m) long The smaller one is of the second most venomous in Australia - it was about 5 feet (1.6m) long I ran over its bigger male brother in an adjacent paddock of grass a week later with a tractor and slasher.
Such snakes adore my storage shed.

When we lose a plane at our flying field (about 12 miles from here) we always watch for snakes in the long grass around the field

Anyway, daylight makes snakes less of a problem you can run faster without bumping into things in the dark

regards
ozphoenix

Now done.
When I put the FCS40 first in the chain, then MLVSS ID1, then MLVSS ID11, everything works as it should (all readings displayed correctly).
When I removed the FCS40 and installed the vario, everything works as it should (all readings displayed correctly).
When I add both the FCS40 AND the vario into the daisy-chain BEFORE the MLVSS ID1, everything works as it should (all readings displayed correctly).
As expected, when I remove both the FCS40 and the vario, the radio loses MLVSS ID1's readings.

Sadly, the last PC/laptop device that I owned which had a standard serial adapter in it died many years ago - all of my devices now have USB There is an extremely thin chance (but extremely) that I might have a working USB/serial converter lying in a box in a storage shed on the other side of my acreage, but that's not somewhere I'd go looking at night, especially on such a slim chance -- have seen many nice sized snakes in and around that shed and in the boxes there over the past few years However, the head office of our local electronics shop franchise has two different Windows 10-compatible DB9-serial-to-USB converters in their catalogue - our local shop is only a small countryside outlet and doesn't carry a lot of stock of such ageing and unusual devices, but I could contact them tomorrow (our time) and ask if they just happen to have one on their local shelf or, if not, how long to get one in -- I'm happy to get one if that would help you a great deal or if my delivery time is less than your delivery time for some local MLVSS devices.

ozphoenix

Could you try connecting the "other" devices first in the daisy chain, then the two MLVSS sensors at the end please?
This is to check if it is a hardware problem or a software problem.
The Rx polls all possible sensors in turn. However, once a sensor is found it is polled much more frequently. So if you have two sensors connected with IDs 1 and 11, the polling sequence is 1, 11, 0, 1, 11, 2, 1, 11, 3 etc. Adding more sensors will reduce the polling rate to known sensors.

I don't know if you have the PC software and hardware to capture the serial data on the Rx SPort signal. It is inverted serial at 57600 baud (0V is line mark, 5V is line space), so a standard serial adapter will connect directly.

Mike

[MikeB]

Had to go out for a while, but I've had a thought. On the QX7, If you disable both internal and external modules, then connect ground and the SPort signal from the Rx to the QX7, I reckon you could create a raw log file of the Rx SPort bus.
I'll try that later today myself. Meanwhile, I'll order a couple of MLVSS sensors.

I had a grass snake in my back garden a few years ago, it went by itself!

Mike

[ozphoenix]

Ok, sounds like a plan - I'd be interested to try that kludge myself but it's fast approaching the time when I turn in to a pumpkin (yes, before midnight), so I'll leave that test up to you and look for an update when you have time

Grass snakes are nice guys - we have tree snakes that are nice guys, too - the big python in the picture (and a slightly smaller one I relocated to the same forest this one went to) was quite calm and pleasant as I was removing him (that's my office door just past the water down-pipe -- he kept peering in through the insect screen on the door), but the Eastern Brown guys (like the one on the tiles) and their mates the Red-Bellied Black ones (saw a monster one down the hill from our house last week) give me the heebie-jeebies -- we don't get along well at all - if they get nasty with me, I return the favour - if they leave willingly, they can leave - while they can. I have an 8year old daughter and a wife to watch out for, not to mention two cats which are prime bait for a python. Due to freakish weather for the past year, Australia is in the midst of an acknowledged boom season for snakes

Looking forward to reading any updates when I surface tomorrow - have a good time

regards,
ozphoenix

Had to go out for a while, but I've had a thought. On the QX7, If you disable both internal and external modules, then connect ground and the SPort signal from the Rx to the QX7, I reckon you could create a raw log file of the Rx SPort bus.
I'll try that later today myself. Meanwhile, I'll order a couple of MLVSS sensors.

I had a grass snake in my back garden a few years ago, it went by itself!

Mike

[MikeB]

OK that worked. On the QX7, I did need to disable the internal module, but enable the external module (no module plugged in) in XJT mode to make the telemetry decoder select SPort telemetry, but I then did manage to capture a raw log file. Just be careful as with the external module enabled, there is battery voltage on the third pin from the bottom in the module bay.
You could use the SPort connector in the base of the QX7 (I can't as my QX7 is an early one without that port working. Stimm best to only connect ground and signal to that.

I've ordered 2 off MLVSS sensors.

Mike

[ReSt]

@ozphoenix
I just have written a small program that reads a raw log file and formats it in a way like this, readable with a normal text editor

Code: Select all

7E 98 10 01 F1 61 00 00 00 9B 
7E 98 10 04 F1 59 00 00 00 A0 
7E 22 10 00 02 00 00 00 00 ED 
7E 16 
7E E9 10 00 03 40 75 57 77 68 
7E B7 
7E 00 10 00 01 1E 46 00 00 8A 
7E 00 10 10 01 00 00 00 00 DE 
7E 39 
7E BA 
7E E9 10 00 03 42 83 77 78 37 
7E 1B 
7E 83 
7E E4 
7E 45 
7E C6 

The only problem, it is a 16 bit program (DOS Program) that runs on Win XP but not on Win10 (and neither Win7 or Win8 I assume)
You start it e.g.
split s6rtest.txt

and it creates a file 'Out.txt'

Reinhard

Split.zip

(27.9 KiB) Downloaded 114 times

[ozphoenix]

Good Morning, Mike (and others),
That's good news (QX7 and MLVSS order).

BTW - isn't the cable you have made to connect in to the back of the QX7 just the same one as you (earlier) recommended for SPort connection to the back of a radio for SPort firmware updates? Ground to bottom pin in the bay (Pin 5?), signal to second from bottom (Pin4?0, stay away from the middle pin (Pin 3 - battery voltage?)? If not, how is this new cable different?

Also, I have a full SPort connection in the back of the XJT external module, which must surely use a normal SPort cable - how is that different using the above-mentioned modified cable directly to the module bay pins?

And, I appear to have an SPort connector (3-pin) in the bottom of my QX7 - I think it's normal production, not pre-production. Is that an option, with a normal SPort cable?

Also, were you able to detect anything promising in the two (one disconnect, one re-connect) patches of .raw file cut-and-paste I posted late yesterday?

regards,
ozphoenix

OK that worked. On the QX7, I did need to disable the internal module, but enable the external module (no module plugged in) in XJT mode to make the telemetry decoder select SPort telemetry, but I then did manage to capture a raw log file. Just be careful as with the external module enabled, there is battery voltage on the third pin from the bottom in the module bay.
You could use the SPort connector in the base of the QX7 (I can't as my QX7 is an early one without that port working. Stimm best to only connect ground and signal to that.

I've ordered 2 off MLVSS sensors.

Mike

[ozphoenix]

Thanks, Reinhard - that certainly makes things easier to read.
Sadly, as with a serial port, the last machine I had that ran a native DOS died long ago. However, I might try a few tricks to get this program running on other machines - will get back to you if I am successful

Again, thanks for the added effort.

regards,
ozphoenix

@ozphoenix
I just have written a small program that reads a raw log file and formats it in a way like this, readable with a normal text editor

Code: Select all

7E 98 10 01 F1 61 00 00 00 9B 
7E 98 10 04 F1 59 00 00 00 A0 
7E 22 10 00 02 00 00 00 00 ED 
7E 16 
7E E9 10 00 03 40 75 57 77 68 
7E B7 
7E 00 10 00 01 1E 46 00 00 8A 
7E 00 10 10 01 00 00 00 00 DE 
7E 39 
7E BA 
7E E9 10 00 03 42 83 77 78 37 
7E 1B 
7E 83 
7E E4 
7E 45 
7E C6 

The only problem, it is a 16 bit program (DOS Program) that runs on Win XP but not on Win10 (and neither Win7 or Win8 I assume)
You start it e.g.
split s6rtest.txt

and it creates a file 'Out.txt'

Reinhard

Split.zip

[ozphoenix]

@Mike - Reinhard's program is very helpful - yesterday, I was thinking whether you might already have such a 'formatter' tool that runs on Windows or else in a Windows10 'cmd.exe' or SuperShell window- any such luck?

I will not have as much time today, as I had yesterday, for this project - have a labourer coming to help me with some acreage work. My answers to questions or requests might be a little delayed, depending on timing.

regards,
ozphoenix

@ozphoenix
I just have written a small program that reads a raw log file and formats it in a way like this, readable with a normal text editor

Code: Select all

7E 98 10 01 F1 61 00 00 00 9B 
7E 98 10 04 F1 59 00 00 00 A0 
7E 22 10 00 02 00 00 00 00 ED 
7E 16 
7E E9 10 00 03 40 75 57 77 68 
7E B7 
7E 00 10 00 01 1E 46 00 00 8A 
7E 00 10 10 01 00 00 00 00 DE 
7E 39 
7E BA 
7E E9 10 00 03 42 83 77 78 37 
7E 1B 
7E 83 
7E E4 
7E 45 
7E C6 

The only problem, it is a 16 bit program (DOS Program) that runs on Win XP but not on Win10 (and neither Win7 or Win8 I assume)
You start it e.g.
split s6rtest.txt

and it creates a file 'Out.txt'

Reinhard

Split.zip

[MikeB]

Cable to the module bay should be signal to the bottom pin (5) and ground to the one above (4). If you argoing to do a raw log file of the receiver SPort, then you must not have the XJT in the back of the radio, you need NO other SPort devices present (hence disable the internal XJT).

The disconnect and re-connect data all look correct.

To format data from log files and suchlike, I generally use a Python script (back on snakes!), as I have Python installed and it is very quick to put a script together.

I do have a Borland, 32-bit compiler so I could probably write a program like Reinhard's that will run in a Windows 10 command box. I haven't used that compiler for a while though.

I'm told that my MLVSS sensors have been dispatched, so I may have them tomorrow.

Mike

[ozphoenix]

Cable to the module bay should be signal to the bottom pin (5) and ground to the one above (4).

I stand corrected - was racing out the door when I scribbled that last note - now have looked at the cable, as I have big labels on each end - yes, confirmed, the Data is definitely the bottom (Pin 5) and Ground is the second from bottom (Pin 4).

Re: dis-connect and connect - I though that you might be able to see something in the data just after disconnect and just before re-connect that might give you a clue - maybe not.

I used to have Borland 32-bit 'C' and 'C++' compilers, years ago, but they are long ago discarded The formatted data makes it so much easier to see what's going on, for newbies like me - maybe you can stare at the data and 'see' it as you move along the lines, but I have to search and stop, search and stop.... maybe such a tool would be useful enough for now and future, that one of our posters can create it in a 32-bit or 64-bit compiler, without taking up your time. Or, can Pythion create an executable for export to standalone use?

Glad you will receive sensors soon - sorry that my little project makes you stock up on previously un-needed devices but, I have a short=term workaround, obviously - just insert the FCS40 into the B17 on one of the batteries or even use a vario (not really needed though), along with 2x MLVSS

Have to go out and do physical work now - will drop back in now and then and see if anyone has posted anything new - provided pythons or browns or blacks are not part of the equation outside today

regards,
ozphoenix

Cable to the module bay should be signal to the bottom pin (5) and ground to the one above (4). If you argoing to do a raw log file of the receiver SPort, then you must not have the XJT in the back of the radio, you need NO other SPort devices present (hence disable the internal XJT).

The disconnect and re-connect data all look correct.

To format data from log files and suchlike, I generally use a Python script (back on snakes!), as I have Python installed and it is very quick to put a script together.

I do have a Borland, 32-bit compiler so I could probably write a program like Reinhard's that will run in a Windows 10 command box. I haven't used that compiler for a while though.

I'm told that my MLVSS sensors have been dispatched, so I may have them tomorrow.

Mike

[ozphoenix]

Mike,
Just a thought, but tomorrow I'll change to the QX7 and also an X4R (instead of 9XRPro and S8R) and see if I get any difference. Cannot get to it tonight.

[MikeB]

My MLVSS sensors have arrived. I can confirm the ID doesn't readily change using the Tx to change it, but I have managed to change it to something else for testing.
I can also confirm that 2 MLVSS on one receiver don't work well. I did have them working once together!
I notice the LED flashing rate also indicates a MLVSS isn't operating fully.
I'll progress some more testing, I can monitor the Rx SPort bus and see what is happening.

Mike

[ReSt]

@ozphoenix

I succeded to get a version of my Split program that is working on Win10.

The only culprit is, you must install it (14 files totally).

The zip file contains a setup.exe that you must run to install the program. The program offers a simple user interface where you can select the input file. The output file will be written to the same path where the input file resides.

Reinhard

WinSplit.zip

Split program that runs on Win10

(1.74 MiB) Downloaded 116 times

[ozphoenix]

Hoorah! While it's normally not good that things don't work, in this case it is! Firstly, I'm relieved it's not just me but, secondly, progress will be faster now that you are able to reproduce the problem in a proper test environment, not across forum posts.

I look forward to your findings, with bated breath!

regards,
ozphoenix

My MLVSS sensors have arrived. I can confirm the ID doesn't readily change using the Tx to change it, but I have managed to change it to something else for testing.
I can also confirm that 2 MLVSS on one receiver don't work well. I did have them working once together!
I notice the LED flashing rate also indicates a MLVSS isn't operating fully.
I'll progress some more testing, I can monitor the Rx SPort bus and see what is happening.

Mike

[ozphoenix]

Hi Reinhard,
Got it! Thanks for going to this extra trouble - it will be useful in this instance, but I think it will also help resolve questions in the future.

I'll install it later this morning and have a look through some files that I've collected, to educate myself a bit more.

Again, thanks and much appreciated.

regards,
ozphoenix

@ozphoenix

I succeded to get a version of my Split program that is working on Win10.

The only culprit is, you must install it (14 files totally).

The zip file contains a setup.exe that you must run to install the program. The program offers a simple user interface where you can select the input file. The output file will be written to the same path where the input file resides.

Reinhard


WinSplit.zip