The device on the right is the sensor hub nano
The problem, of course, is that Infineon is a hardware company. Need to know some hardware related detail? They have reams of charts and graphs. But the Bluetooth spec for the device so we can actually poke at it and get data outside of their Android app? That’s a much harder task.
Well, here’s a little dump of what I’ve learned. The device acts like a serial port (and therefore commits one of the sins from my ‘your Bluetooth is bad’ post).
Commands going in start with a $ and end with just a newline. Data coming back is either JSON format (for the meta-data you can get) or not. But either way, the return data also starts with a $. Except when it starts with a >, like it echoes (some) bad commands.
Initial Messages:
Send these three strings
$hello
$info
To the $hello message the device replies with
${"pt":"urn:{557C199C-D246-43D5-8079-A68986BBAEB1}","uuid":"","username":""}
${"pt":"urn:{557C199C-D246-43D5-8079-A68986BBAEB1}","uuid":"","username":""}
To the $info message the device replies with
${"name":"IFX_NanoHub","manufacturer":"Infineon","protocol":"1.1","fw":"BSL111_FW312-b16ca0f","baud":115200,"sensors":["1"]}
${"name":"IFX_NanoHub","manufacturer":"Infineon","protocol":"1.1","fw":"BSL111_FW312-b16ca0f","baud":115200,"sensors":["1"]}
Yes, it seems to send the same data out twice. And note the silliness with the baud rate – as you all should know, you don’t ever set the internal Bluetooth baud rate.
The you get get more info about the sensors with
$sinfo id=1
The device responds with
${"id":"1",
"manufacturer":"Infineon",
"type":"DPS310",
"chip_id":0,
"port":0,
"dds":[
{
"name":"Pressure",
"id":"p",
"type":"d",
"unit":"mBar"
},
{
"name":"Altitude",
"id":"a",
"type":"d",
"unit":"m"
},
{
"name":"Temperature",
"id":"t",
"type":"d",
"unit":"degC"
}
]
}
${"id":"1","manufacturer":"Infineon","type":"DPS310","chip_id":0,"port":0,"dds":[{"name":"Pressure", "id":"p", "type":"d","unit":"mBar"},{"name":"Altitude", "id":"a", "type":"d","unit":"m"},{"name":"Temperature", "id":"t", "type":"d","unit":"degC"}]}
BTW, I took the results and split them onto multiple lines. Yes, you once again get the duplicated answer. But see how we can tell what data we’re going to get, and how we can tell what kinds of sensors are available. In theory, Infineon engineers can use the “same” protocol for multiple boards.
Then you can set the sensor modes. It seems like you can get by with just sending the $start_sensor command
$set_mode sid=1;md=mode;val=bg
$set_mode sid=1;md=prs_osr;val=16
$set_mode sid=1;md=prs_mr;val=32
$start_sensor id=1
A set_mode command with correct parameters results in $ack and a bad one results in $nack
Stop the flood of sensor data with the $stop command
$stop
The flood of sensor data looks like this. The first number is the sensor id, the second is what's being produced (a=altitude, t=temp, p=pressure) based on the sinfo results. The last value is a timestamp.
$1,a,27.8411,282787
$1,t,35.0797,284036
$1,p,1009.9077,284036
$1,a,27.8638,284036
$1,t,35.0619,285286
$1,p,1009.9113,285286
Good luck hacking your infineon!
