Hi Andrew,
Pleased to be of any assistance.
The first 21 bits appear to always remain constant
111111111110101000101
This would probably be the header (1's + a Zero) and the ID of the type of unit it is in the Ambient range.
The next 8 bits appear to reset randomly each time there is a battery change
01001111
this is to distinguish your system (hopefully) from any other nearby Ambient transmitter of the same type, eg a Neighbour's WS with the same ID
Your next analysis I can only agree with as having a system to experiment with is the only way of checking, ie check Arduino outputs with what the Ambient console is showing. I don't have one to experiment with. However going on your evidence I have doctored my debug version for my old Bios/Thermor WS for you to try and further develop if you get any success from it.
I believe the Bios protocol shares a few important aspects with the Ambient. Such as lo-hi=>1, hi-lo=>0 for the Manchester Encoding. I am not sure if it has the first (sync) 0 within the byte boundaries or outside them. I have indicated in the program where you can alter that to try either way. You have to look where your other data is falling to work it out. eg does the temp and humidity data fall squarely within bytes? The Bios WS did not have a checksum as it sent the whole packet 4 times over each time, so getting 4 identical packets was how the data was validated. Given the Ambient sends the data 3 times I have adjusted the program to look for 3 identical packets. Also the Bios had about 80 header bits, more than enough I think!!! The Ambient looks to have about 10 or 11 so I have adjusted the program to look for 7, so we have a few left over (the program just dumps any excess).
The program is also set up for you to dump the whole three packets into a byte array and then dump this out as binary for your inspection. At the moment it only dumps out when it gets three identical packets, however you may need to change it to have it dump/debug all three packets separately to look at what you are getting if they are not identical first up. The program is set to capture 6 bytes (I counted 54 bits in the packet (including a few 0's at the end that looked like padding) so I thought 6x8=48 should be an ok number to collect. Change it to 5 if you find you can't validate with 6.
The last bits after the humidity could be just junk for padding. Anyway you can have a look as see what they do once you get it dumping binary/hex. For example all the data you really need to check maybe in the first 5 bytes and you will be able to ignore the last byte if it has random junk in it. However it could also be a checksum as you say. My Oregon Scientific WS on the other hand does not repeat the sensors's packet and has a simple summing check-byte at the end of the data bytes, not a difficult polynomial check like some have. I do have a reference to one of these I can dig out, but I would be betting on no check sum with a repeat of three packets occurring.
The rest of the program is to do with processing the packets according to the Bios WS rules, you will need to devise your own for the Ambient to suit your application, however I hope they don't just get in the way and do help you formulate your own calculation routines.
I have run a compile check on the program and it appears error free in that respect, however the chances I have cracked a perfect score for you so it "runs straight out of the box" are very slim, so I wish you all the best to get any final wrinkles out of it. Eg enable the printing of the "H" when a valid header is received, if you need to check that).
Let us know how you go, best wishes,
Rob
DebugVersion.ino (18.5 KB)