@JonnyMac Thanks for posting this! Looking at your two sensors, I think I may have determined a new rule for packets based on the sensor data you posted. The last byte in the packet appears to be the sum of all bytes sent (which should be $xxFF) minus it's own MSByte.
Your telemetry data packet of 06 A1 69 02 ED has a checksum of $01_FF, the last byte is $FF-$01, therefore $FE.
Your telemetry data packet of 06 A2 FB FF 5D has a checksum of $02_FF, the last byte is $FF-$02, therefore $FD.
This might explain some packets being rejected that I created with the P2, as I thought all telemetry data packets ended in $FE and hard coded that. I will test this evening and report back. This would end all magic numbers from my code, with the exception of the packet type.
I couldn't wait. Yes! This is correct and now accepts values as expected.
iBus sensor packet definition:
First Octet
Number of bytes within the packet.
Second Octet
Interrogatory & Response: $80+x Sensor Exists at address X
Interrogatory & Response: $90+x Sensor Type at address X
Interrogatory & Response: $A0+x Sensor Data at address X
Third Octet
Interrogatory & Response Sensor Exists: 2nd to last Octet
Interrogatory Sensor Type: 2nd to last Octet
Interrogatory Sensor Data: 2nd to last Octet
Response Sensor Type: Sensor Type code.
Response Sensor Data: LSByte of Sensor Data
Fourth (or more) Octet
Interrogatory & Response Sensor Exists: Last Octet
Interrogatory Sensor Type: Last Octet
Interrogatory Sensor Data: Last Octet
Response Sensor Type: Number of bytes returned for Sensor Data
Response Sensor Data: next MSByte of Sensor Data, etc...
2nd to last Octet
Interrogatory & Response: Chucksum padding: $FF minus (Sum of all previous bytes, MOD 256)
Last Octet
All Interrogatory & Response packets: Checksum: (Sum of all previous bytes, MOD 256) minus (Sum of all previous bytes Shift Right 8).
The temperature data (sensor 1) seems to be in C, tenths of a degree, plus 400. $0285 = 645, 645-400 = 245 (display says 24.5C).
The voltage data (sensor 2) seems to be in 1/100th volts. I connected to a Vdd rail on the Eval and the display read 3.22 volts (reading was 322).
Excellent! Is there a way to take direct voltage reading with the P2, though a Sigma Delta type circuit? I seem to recall an application note for the P1. Would be nice to directly read the battery voltage of the main power directly off the battery.
I want to build an autopilot with the P2. Would be cool to flip a switch on the FlySky and it put my plane in "loiter" mode.
Comments
@JonnyMac Thanks for posting this! Looking at your two sensors, I think I may have determined a new rule for packets based on the sensor data you posted. The last byte in the packet appears to be the sum of all bytes sent (which should be $xxFF) minus it's own MSByte.
Your telemetry data packet of 06 A1 69 02 ED has a checksum of $01_FF, the last byte is $FF-$01, therefore $FE.
Your telemetry data packet of 06 A2 FB FF 5D has a checksum of $02_FF, the last byte is $FF-$02, therefore $FD.
This might explain some packets being rejected that I created with the P2, as I thought all telemetry data packets ended in $FE and hard coded that. I will test this evening and report back. This would end all magic numbers from my code, with the exception of the packet type.
I couldn't wait. Yes! This is correct and now accepts values as expected.
iBus sensor packet definition:
First Octet
Number of bytes within the packet.
Second Octet
Interrogatory & Response: $80+x Sensor Exists at address X
Interrogatory & Response: $90+x Sensor Type at address X
Interrogatory & Response: $A0+x Sensor Data at address X
Third Octet
Interrogatory & Response Sensor Exists: 2nd to last Octet
Interrogatory Sensor Type: 2nd to last Octet
Interrogatory Sensor Data: 2nd to last Octet
Response Sensor Type: Sensor Type code.
Response Sensor Data: LSByte of Sensor Data
Fourth (or more) Octet
Interrogatory & Response Sensor Exists: Last Octet
Interrogatory Sensor Type: Last Octet
Interrogatory Sensor Data: Last Octet
Response Sensor Type: Number of bytes returned for Sensor Data
Response Sensor Data: next MSByte of Sensor Data, etc...
2nd to last Octet
Interrogatory & Response: Chucksum padding: $FF minus (Sum of all previous bytes, MOD 256)
Last Octet
All Interrogatory & Response packets: Checksum: (Sum of all previous bytes, MOD 256) minus (Sum of all previous bytes Shift Right 8).
The temperature data (sensor 1) seems to be in C, tenths of a degree, plus 400.
$0285 = 645, 645-400 = 245 (display says 24.5C).The voltage data (sensor 2) seems to be in 1/100th volts. I connected to a Vdd rail on the Eval and the display read 3.22 volts (reading was 322).
Excellent! Is there a way to take direct voltage reading with the P2, though a Sigma Delta type circuit? I seem to recall an application note for the P1. Would be nice to directly read the battery voltage of the main power directly off the battery.
I want to build an autopilot with the P2. Would be cool to flip a switch on the FlySky and it put my plane in "loiter" mode.
Remember... the P2 has smart pin ADCs. No sigma-delta circuit required for 0-3.3v.
So a 10/1 voltage divider (10000 ohms / 1000 ohms) should allow for measuring up to 33.00 volts?
You need a 9000 Ohm and 1000Ohm if you want 33V on input to be 3,3V on output.
@MAElektronik Ah, you are correct! Thanks!