HoTT protocol and current/capacity integration

[onki69]

The old OxS supported the very popular HoTT protocol for telemetry.
Is it planned to migrate this into the RP2040 project?
What about current and capacity?
Of course a current is nothing else than voltage at a sensor (shunt or hall sensor) but it is a different parameter in the telemetry protocol. Same applies to the capacity. Only FrSky calculates that in the transmitter software but not the others.

Best regards
Onki

P.S. I really like this project and the tiny little Pi Pico Zero. The configuration through the terminal is much more convenient than the config file solution.

[mstrens]

If there is interest, I could add the Hott protocol to oXs on RP2040 in the same way it was done in oXs for AVR 328P.

Still, I would like to avoid too many parameters to set up. So the user does not have to compile him self and can just flash the RP2040 with a simple drag and drop.
So I propose to take a convention saying that voltage 4 is always considered as a current and is transmitted as current in all protocols.
Then, I can use voltage 4 to calculate the consumed capacity since power on.
Please note that this is not the best solution because normally the user would be more interested in the remaining capacity percentage. But this would require that the Tx sent command/parameter to oXs in order to let the user say

• when a new battery is installed
• what is the max capacity of the battery.
  This makes implementation of a protocol more complex and I would like to avoid it.
  This complexity does not exist with openTx (or similar) because those parameters can be defined on Tx side instead of on sensor side.

[onki69]

For me this is a good solution.
I am not using the remaining capacity at all because I know my battery and set alarm levels when I have reached 80% of the used capacity.
Keep it simple with the capacity. Just do a reset every time you power up the sensor and as an useful alternative if the last measured voltage is significantly lower than now (new battery used). Many user fly more than once with a battery pack and like the way of capacity reset. This may require to save the voltage in the flash maybe once every 10 seconds.
If someone is not able to calculate maybe a Lua-Script could handle this.

[mstrens]

I could try to implement the Hott protocol in oXs on RP2040 but I do not have Graupner TX/RX.
Could you then test/debug the code I should write?

[mstrens]

I added the code for HOTT protocol but I could not test it.
The program is available in a branch named HOTT.
Please test it and let me know if it is OK.
I can then move this program to the master branch

[onki69]

I have tested the branch code on my standard setup with a HoTT receiver and a Radiomster TX16S with latest MPM firmware.
I was able to switch the protocol to "H" (HoTT) but I don't get any telemetry data on the transmitter (EdgeTX 2.8).
This is the console output:
`Protocol is Hott (Ex)<\r><\n>
CRSF baudrate = 420000<\r><\n>
Voltage parameters:<\r><\n>
Scales : 1.000000 , 1.000000 , 1.000000 , 1.000000 <\r><\n>
Offsets: 0.000000 , 0.000000 , 0.000000 , 0.000000 <\r><\n>
RPM multiplier = 1.000000<\r><\n>
Baro sensor is detected using MS5611<\r><\n>
Sensitivity min = 100 (at 100) , max = 300 (at 1000)<\r><\n>
Hysteresis = 5 <\r><\n>
First analog to digital sensor is not detected<\r><\n>
Second analog to digital sensor is not detected<\r><\n>
Foreseen GPS type is Ublox :GPS is detected<\r><\n>
Failsafe type is HOLD<\r><\n>
<\r><\n>
Config parameters are OK<\r><\n>
<\r><\n>

<\r><\n>
`

With GPS fix still no additional telemetry data, just the 8 standard HoTT values.
I switched over to S.Port and got all data with a R168 receiver and FrSky protocol.

[Satcomix]

Hello Mstrens,
Many thanks for the whole development of the openXsensor or oXs_on_RP2040,
With the S.Port protocol of my FrSky X20S Ethos 1.4.6 and TD-R10 receiver I have never had any problems with oXs_on_RP2040 or openXsensor_on_328P.
Everything works as it should, with no noticeable errors.
I've tried everything with the HOTT protocol on Ver.0.4.3_HOTT on RP2040, but I'm not getting any data/sensor values ​​on the MC28.
Nothing is found except the GR-24 receiver values. With openXsensor Ver.8.2.15 HOTT protocol everything works fine.
Best regards,
Torsten

[mstrens]

I looked at the code for Hott protocol.
I found 2 bugs.
Perhaps there are still some other.
I put on github version 0.5.0 to fix those 2 bugs.
Please test already this.
In Hott protocol, the receiver sent a request to the sensor.
I expect that the handset must be configured to know which kind of sensor has to be discovered/read.
oXs is supposed to emulate only 2 types of sensor (GAM and GPS)
In order to know if oXs can detect this "request", this version is supposed to print (to the PC) a character "r" every time a GAM or GPS request is received.
Please test already this part.
oXs is also supposed to reply. I made a change that could explain why it did not work. Perhaps is it now OK?

[Satcomix]

Hello Mstrens,
Ver.0.5.0-hott
Continue with the HOTT protocol, MC28-GR24-HOTT does not find any sensors from the oXs, only the receiver with sensors is displayed.
At terminal comes an rrrrrrrrrrrrrrrr...........
br,
Torsten

[onki69]

Same here with GR-16 and TX16S with MPM (HoTT).
Just the receiver values are comiong with 0.5.0-hott.
Switching to S.Port and using a R168 receiver it all works like a charm.

[mstrens]

the rrrrrrrrrrrrrrrr.... is already a good point.
It means that oXs detect the request from receiver.
I will check once more and make a version that should print mode debug info.

[mstrens]

I made some changes for Hott protocol in a version 0.5.1 that is on github.
I hope it will work.
Please test it.

[Satcomix]

Good Morning Mstrens,
First Test : MC28 HOTT shows Receiver, General Modul and GPS. Super!!!!
MC28--GR24 --GY86 with MS5611 and MP6050, GPS BN220.
I make some more Test.
Version = 0.5.1
Function Code Pin (255=disabled)
Primary channels input PRI = 255
Secondary channels input SEC = 255
Telemetry TLM = 12
GPS Rx GPS_RX = 0
GPS Tx GPS_TX = 1
Sbus OUT SBUS_OUT= 255
RPM RPM = 255
SDA (baro sensor) SDA = 2
SCL (baro sensor) SCL = 3
PWM Channels 1, 2, 3 ,4 C1 / C4 = 255 255 255 255
PWM Channels 5, 6, 7 ,8 C5 / C8 = 255 255 255 255
PWM Channels 9,10,11,12 C9 / C12= 255 255 255 255
PWM Channels 13,14,15,16 C13/ C16= 255 255 255 255
Voltage 1, 2, 3, 4 V1 / V4 = 26 255 255 255

Protocol is Hott
CRSF baudrate = 420000
Voltage parameters:
Scales : 1.000000 , 1.000000 , 1.000000 , 0.100000
Offsets: 0.000000 , 0.000000 , 0.000000 , 0.000000
RPM multiplier = 1.000000
Baro sensor is detected using MS5611
Sensitivity min = 100 (at 100) , max = 300 (at 1000)
Hysteresis = 5
Acc/Gyro is detected using MP6050
First analog to digital sensor is detected using ads1115
Measurement setup: 0 , 8 , 8 ,8
Gains: 2 , 2 , 2 ,2
Rates: 7 , 4 , 4 ,7
Offsets: 0.000000 , 0.000000 , 0.000000 ,0.000000
Scales: 1.000000 , 1.000000 , 1.000000 ,1.000000
Averaged on: 10 , 20 , 30 ,50
Second analog to digital sensor is detected using ads1115
Measurement setup: 0 , 8 , 8 ,8
Gains: 2 , 2 , 2 ,2
Rates: 7 , 4 , 4 ,7
Offsets: 0.000000 , 0.000000 , 0.000000 ,0.000000
Scales: 1.000000 , 1.000000 , 1.000000 ,1.000000
Averaged on: 10 , 20 , 30 ,50
Foreseen GPS type is Ublox :GPS is detected
Failsafe uses predefined values
Chan 1...4 = 992 , 992 , 992 , 992
Chan 5...8 = 992 , 992 , 992 , 992
Chan 9...12 = 992 , 992 , 992 , 992
Chan 13...16= 992 , 992 , 992 , 992

Config parameters are OK
Greatings,
Torsten

[Satcomix]

Second Test with MC28-GR24-HOTT,
GPS BN220 is OK
V1 = AKK1 Volt1
V2 = Ampere1
V3 = Volt2 above Ampere1 Display
V4 = AKK2 Volt3
Is there something in Script where i can switch to temperature T1 and T2 ???
The Gy86 with MS5611 and MP6050 doesnt show values on telemetry display. ???
In Terminal -> Baro sensor is detected using MS5611 ->Acc/Gyro is detected using MP6050
br,
Torsten

[Satcomix]

Hello Mstrens,
there is a little bug in the 0.5.1-hott release
I switch between GY86 incl-MS5611/ MP6050 and BMP280 for testing.
But the MP6050 is still showing in Terminal !

Protocol is Sport (Frsky)
CRSF baudrate = 420000
Voltage parameters:
Scales : 10.000000 , 10.000000 , 10.000000 , 10.000000
Offsets: 0.000000 , 0.000000 , 0.000000 , 0.000000
RPM multiplier = 1.000000
Baro sensor is detected using BMP280
Sensitivity min = 100 (at 100) , max = 300 (at 1000)
Hysteresis = 5
Acc/Gyro is detected using MP6050
First analog to digital sensor is not detected
Second analog to digital sensor is not detected
Foreseen GPS type is Ublox :GPS is detected
br,
Torsten

[mstrens]

There is currently nothing to fill temperature1 or 2.
For hott currently:

• volt1 = Battery 1
• volt 2 = current
• volt 3 = capacity
• volt4 = battery 2 (and probably less digits)

I put on github a version 0.5.2 that is supposed to fix the wrong detection of MP6050.
In this version, I also add one line of code in order to print to the PC the value of Vspeed each time a (GAM) Hott frame is generated. The idea is just to debug if there is a value of Vspeed available. This could perhaps help to understand why you do not get Vspeed on the handset. Note: the value that is printed is the real Vspeed(cm/sec) + 30000 because the hott protocol requires an offset of 30000. So the real Vspeed should be (printed value-30000)

[Satcomix]

Hello Mstrens,
thank you for your reply and your work!!!
Now my RC MC28 HOTT shows me the hight ca.1-2m and the second value jumps a little bit with +- it seems ok.
Test: MC28-GR24-HOTT-oXs-GPS-BN220-Vario-GY86incl.MS5611andMP6050,V1-V4
It shows:
v= 30974
v= 30417
v= 30062
v= 29863
v= 29838
v= 29884
v= 29959
v= 30016
v= 30016
v= 30022
v= 30023
v= 29996
v= 29996
v= 29989
v= 30001
v= 30008
v= 30000
v= 30001
v= 30001
v= 30001
v= 30006
v= 30000
v= 30006
v= 29999
v= 29999
v= 29999
v= 30006
v= 30007
v= 30007
v= 30001
v= 30007
v= 29993
v= 29999
v= 29999
v= 29991
v= 29998
v= 30005
v= 30005
v= 30000
v= 30006
v= 29994
v= 30008
v= 30008
v= 30001
v= 29995
v= 30000
v= 29998
v= 30003
v= 30003
v= 30003
v= 30010
v= 29996
v= 29996
v= 30001
v= 30008
v= 30002
v= 30002
v= 30009
v= 30003
v= 30003
v= 29996
v= 29996
v= 30002
v= 30002
v= 30002
v= 30002
v= 30005
v= 29984
v= 29985
v= 30012
v= 30030
v= 30042
v= 29993
v= 29987
v= 29994
v= 29927
v= 30001
v= 30014
v= 30069
v= 30095
v= 30009
v= 29936
v= 29901
v= 29974
v= 30023
v= 30029
v= 30008
v= 30008
v= 30008

[Satcomix]

Everything is OK
MP6050 is not detected.
Cmd to execute:

Version = 0.5.2
Function Pin Change entering XXX=yyy (yyy=255 to disable)
Primary channels input = 255 (PRI = 5, 9, 21, 25)
Secondary channels input = 255 (SEC = 1, 13, 17, 29)
Telemetry . . . . . . . . = 12 (TLM = 0, 1, 2, ..., 29)
GPS Rx . . . . . . . . . = 0 (GPS_RX = 0, 1, 2, ..., 29)
GPS Tx . . . . . . . . . = 1 (GPS_TX = 0, 1, 2, ..., 29)
Sbus OUT . . . . . . . . = 255 (SBUS_OUT= 0, 1, 2, ..., 29)
RPM . . . . . . . . . . = 255 (RPM = 0, 1, 2, ..., 29)
SDA (I2C sensors) . . . . = 2 (SDA = 2, 6, 10, 14, 18, 22, 26)
SCL (I2C sensors) . . . . = 3 (SCL = 3, 7, 11, 15, 19, 23, 27)
PWM Channels 1, 2, 3 ,4 = 255 255 255 255 (C1 / C16= 0, 1, 2, ..., 15)
PWM Channels 5, 6, 7 ,8 = 255 255 255 255
PWM Channels 9,10,11,12 = 255 255 255 255
PWM Channels 13,14,15,16 = 255 255 255 255
Voltage 1, 2, 3, 4 = 26 27 28 29 (V1 / V4 = 26, 27, 28, 29)

Protocol is Hott
CRSF baudrate = 420000
Voltage parameters:
Scales : 10.000000 , 10.000000 , 0.200000 , 0.300000
Offsets: 0.000000 , 0.000000 , 0.000000 , 0.000000
RPM multiplier = 1.000000
Baro sensor is detected using BMP280
Sensitivity min = 100 (at 100) , max = 300 (at 1000)
Hysteresis = 5
Acc/Gyro is not detected
First analog to digital sensor is not detected
Second analog to digital sensor is not detected
Foreseen GPS type is Ublox :GPS is detected
Failsafe type is HOLD

Config parameters are OK
v= 30020
v= 30020
v= 30020
v= 30020
v= 30020
v= 30020
v= 30020
v= 30020
v= 30020
v= 30020
v= 30026
v= 30026
v= 30026
br,
Torsten

[onki69]

I could test 0.5.2.
The GPS seems to work properly ( I just need a long time to find a fix because of poor reception).
Vario always shows 1.3m/s. Does not seem to work.
There are many empty values but I think this is because of the Graupner multi sensor philosophy.

When switching to S.Port the GPS height values are 10 times higher than with Hott (5200m instead of 520m).
This is fixed in 0.5.4 but there is a TMP1 value always at 106°C

Best regards and thanks for your great work
Onki

[mstrens]

About vario I have a few questions:

• do you use a MP6050? If so, it could be that your MP6050 requires some calibration (procedure still to be added)
• is the value the same in Hott and in Sport protocols?

In Hott, oXs simulates GAM device and this contains a lot of fields that oXs does not measure. This explain lot of 0).

Perhaps there is a bug in Sport Gps Height. Is your real altitude around 520m?
Anyway, this is strange because nobody noticed such an issue.
Furthermore, I did not make change in Sport between 0.5.2 and 0.5.4.

TMP1 is also strange. I do not sent TMP1.

I suggest that, in Sport, you first delete all sensors (on the handset) and that you ask afterward to discover them again.

[onki69]

I am using the MS6511 (GY-86) as baro sensor for my varios.
All telemetry values were deleted but I'll try again both protocols this evening.
My real altitude is in the range of 500m (above sea level).

[mstrens]

I made a change this morning.
In some previous versions oXs sent GPS height immediately (without waiting for a fix).
In this case, frist GPS height are totally inaccurate.
It could be that your handset take the first value as reference and afterward use it to calculate a "relative" altitude.
I now change the code in order to avoid sending height (and some other GPS data except number of sat) as long there is no fix 3D. This will perhaps solve the issue.

[onki69]

I am just testing the 0.5.6 (with GR-16 and TX16S / EdgeTX 2.8)

With Hott GPS seems to work now. But all GAxx labelled values are red (no Vario).
Once in a while (about every minute) I do get data with the GAxx vlaues for about a second.

[mstrens]

I put on github a version 0.5.7 where I removed the display on PC of the GPS data (height) as this seems OK.
I also add the possibility to request a calibration of the MP6050 (acc & gyro).
In this version, the calibration values are not saved permanently (lost at power off).
To perform the calibration MP6050 must stay in a fixed position (flat on a table) with the Ic's (sensors) up.

I am not sure at all that this version should fix the issue about vario data not being regularly updated in Hott protocol.
Could some others confirm this issue in Hott?
Is the issue present with and without use of a MP6050?
Do you get other GAM data e.g. a battery voltage when pin for Volt1 is defined? And does it change something if GPS and all I2C are disabled?
In the hott protocol, there are some timing to respect (delay between RX request and begin of reply, delay between each char being sent to the receiver). Perhaps I do not respect some of the timing.
Still, it is strange that is works for GPS because I use the same timings for GPS and GAM(vario/voltage).
Ideally, someone having an official hott sensor and a logic analyser could capture the signal between Rx and sensor in order to have the precise values of the timing to respect.

[Satcomix]

Hello Mstrens,
I have a MC28-GR24 HOTT and a Kingst 16Ch LogicAnalyzer,
but NO official Graupner HOTT Sensor, can we do it with oXs in a certain kind?
br,
Torsten

[mstrens]

Thanks for the proposal but the idea is just to have a look at the "official" timings.
I have also a logic analyser that I used to debug the way oXs generates the signal.
It helped me to find some bug a few days ago but I am not sure that the delays I use fit the hott requirements.
Still, if it works with GPS frames, I presume it should also work for GAM frames.

[Satcomix]

With the older oXS Ver.8.2.15 ,i have voltage, temp,gps,....and everything works very good
When i read the timing from the S.Port Line with the Analyzer, why not?
br,
Torsten

[mstrens]

@Satcomix
Do you have notice also an issue with oXs on RP2040 for Volt1, Vspeed and baro altitude (missing values or values refreshed only from time to time) or is this issue present only for another user?

[Satcomix]

V1, V2, Current, Capacity and GPS are ok, tomorow i will test vario again, and make a special build of oXs on 328P.
br,
Torsten

[mstrens]

If V1, V2 from oXs on RP2040 are ok on handset, then timings seems OK (at least for your RX and handset).
So, I imagine that Vspeed and alt will be Ok also.

Perhaps the user having the issue is using another type of Rx and/or handset but then I do not see why it should work for GPS?

[Satcomix]

Good morning Mstrens,
I tested the original Graupner MC28-4D with GR-24 receiver again with oXs_on_RP2040 Ver.0.5.7-hott.
Conclusion: software runs very stable without debug display, no reconnection of the USB UART or any other problem, as in the past.
The Handheld can find in Telemetry Sensors the Receiver, General Modul, and GPS

The handheld display shows the following:
V1=AKK1 Sensor1 Volt1 with Scale 1/10,
V2=Current1 in A with Scale 1/10,
V3=Volt2 above Current1 with Scale 1/10,
V4=AKK2 Sensor2 Volt3 with Scale 1/10.

GPS BN220: Altitude MSL (real height above sea level), GPS Dir in °, distance home in meters, GPS speed, 3D FIX, number of received satellites.

Vario BMP280 with +/- altitude and +/- rate of climb in m/s,it showed me plausible data.
Vario GY86 incl. MS5611 and MP6050 with +/- altitude and +/- rate of climb in m/s,it showed me plausible data.

Test1 HOTT with BMP280:
Version = 0.5.7
Function Pin Change entering XXX=yyy (yyy=255 to disable)
Primary channels input = 255 (PRI = 5, 9, 21, 25)
Secondary channels input = 255 (SEC = 1, 13, 17, 29)
Telemetry . . . . . . . . = 12 (TLM = 0, 1, 2, ..., 29)
GPS Rx . . . . . . . . . = 0 (GPS_RX = 0, 1, 2, ..., 29)
GPS Tx . . . . . . . . . = 1 (GPS_TX = 0, 1, 2, ..., 29)
Sbus OUT . . . . . . . . = 255 (SBUS_OUT= 0, 1, 2, ..., 29)
RPM . . . . . . . . . . = 255 (RPM = 0, 1, 2, ..., 29)
SDA (I2C sensors) . . . . = 2 (SDA = 2, 6, 10, 14, 18, 22, 26)
SCL (I2C sensors) . . . . = 3 (SCL = 3, 7, 11, 15, 19, 23, 27)
PWM Channels 1, 2, 3 ,4 = 255 255 255 255 (C1 / C16= 0, 1, 2, ..., 15)
PWM Channels 5, 6, 7 ,8 = 255 255 255 255
PWM Channels 9,10,11,12 = 255 255 255 255
PWM Channels 13,14,15,16 = 255 255 255 255
Voltage 1, 2, 3, 4 = 26 27 28 29 (V1 / V4 = 26, 27, 28, 29)

Protocol is Hott
CRSF baudrate = 420000
Voltage parameters:
Scales : 10.000000 , 10.000000 , 10.000000 , 10.000000
Offsets: 0.000000 , 0.000000 , 0.000000 , 0.000000
RPM multiplier = 1.000000
Baro sensor is detected using BMP280
Sensitivity min = 100 (at 100) , max = 300 (at 1000)
Hysteresis = 5
Acc/Gyro is not detected
First analog to digital sensor is not detected
Second analog to digital sensor is not detected
Foreseen GPS type is Ublox :GPS is detected
Failsafe type is HOLD

Config parameters are OK

Test2 HOTT with GY86:
Version = 0.5.7
Function Pin Change entering XXX=yyy (yyy=255 to disable)
Primary channels input = 255 (PRI = 5, 9, 21, 25)
Secondary channels input = 255 (SEC = 1, 13, 17, 29)
Telemetry . . . . . . . . = 12 (TLM = 0, 1, 2, ..., 29)
GPS Rx . . . . . . . . . = 0 (GPS_RX = 0, 1, 2, ..., 29)
GPS Tx . . . . . . . . . = 1 (GPS_TX = 0, 1, 2, ..., 29)
Sbus OUT . . . . . . . . = 255 (SBUS_OUT= 0, 1, 2, ..., 29)
RPM . . . . . . . . . . = 255 (RPM = 0, 1, 2, ..., 29)
SDA (I2C sensors) . . . . = 2 (SDA = 2, 6, 10, 14, 18, 22, 26)
SCL (I2C sensors) . . . . = 3 (SCL = 3, 7, 11, 15, 19, 23, 27)
PWM Channels 1, 2, 3 ,4 = 255 255 255 255 (C1 / C16= 0, 1, 2, ..., 15)
PWM Channels 5, 6, 7 ,8 = 255 255 255 255
PWM Channels 9,10,11,12 = 255 255 255 255
PWM Channels 13,14,15,16 = 255 255 255 255
Voltage 1, 2, 3, 4 = 26 27 28 29 (V1 / V4 = 26, 27, 28, 29)

Protocol is Hott
CRSF baudrate = 420000
Voltage parameters:
Scales : 10.000000 , 10.000000 , 10.000000 , 10.000000
Offsets: 0.000000 , 0.000000 , 0.000000 , 0.000000
RPM multiplier = 1.000000
Baro sensor is detected using MS5611
Sensitivity min = 100 (at 100) , max = 300 (at 1000)
Hysteresis = 5
Acc/Gyro is detected using MP6050
First analog to digital sensor is not detected
Second analog to digital sensor is not detected
Foreseen GPS type is Ublox :GPS is detected
Failsafe type is HOLD

Config parameters are OK

I hope I was able to present my results clearly, Thank you.
br,
Torsten

[Satcomix]

@onki69
I think that the feature request for the Graupner HOTT protocol has been checked for a long time and is therefore settled.
Could you please close the issue as author, thanks.
br,
Torsten