Reading Wireless Air Transmitter using Arduino

Please register or login

Welcome to ScubaBoard, the world's largest scuba diving community. Registration is not required to read the forums, but we encourage you to join. Joining has its benefits and enables you to participate in the discussions.

Benefits of registering include

  • Ability to post and comment on topics and discussions.
  • A Free photo gallery to share your dive photos with the world.
  • You can make this box go away

Joining is quick and easy. Log in or Register now!

I'm quite inexperienced with this sort of thing, how did you convert the green to my ID? I've put it into plenty of online binary to decimal converters and gotten the wrong numbers.

I did it wrong. Sorry. I don't know how to decode the green.
 
@rg422 great work!

I've been puzzling over matching the Transmitter ID/decoding the green field and I haven't been able to make it work in with the "104308" being decimal or HEX and mapping to the binary string as BCD, ASCII, grey-code, XC3 or plain binary in the section before the blue.

I expect that the pressure field will be at least 12-bit since the transmitters are listed as up to 4000 psi and 12 bits gives 0-4095. Of course mine is also labled 300Bar which would require 13 bits.

I have a suspicion that once we crack the transmitter encoding, we may find that the battery status is before the pressure group, and that the purple end field is some sort of CRC or checksum validation.

Fresh eyes in the morning ...
 
I expect that the pressure field will be at least 12-bit since the transmitters are listed as up to 4000 psi and 12 bits gives 0-4095. Of course mine is also labled 300Bar which would require 13 bits.

I have a suspicion that once we crack the transmitter encoding, we may find that the battery status is before the pressure group, and that the purple end field is some sort of CRC or checksum validation.
^ Both sound likely to me. I won't have time the next couple days to work on this but I look forward to hearing if you all make any developments. This weekend I will record more samples with known battery voltages as well. If anyone in the San Diego area has a transmitter I could sniff with the RSP1a we would be able to determine exactly where the ID is located.
 
@rg422 I've been puzzling over matching the Transmitter ID/decoding the green field and I haven't been able to make it work in with the "104308" .

Me too, also without any luck. Closest I can get is a scheme that decodes as 204308. It would be helpful to have another ID example to work with. Hopefully someone near @rg422 will loan him a transmitter and help this project along.
 
How did you do this?
I didn't post the method as I do not believe it is correct, but as you ask here it is...
2022-02-10_112527.jpg

Data stream with different transmitters IDs would be very helpful. As well as some streams with known battery voltage values.
 
I didn't post the method as I do not believe it is correct, but as you ask here it is...
View attachment 706365
Data stream with different transmitters IDs would be very helpful. As well as some streams with known battery voltage values.
So you are inverting (NOT), then reverse bit-ordering each Nibble (4-bits), and taking the MOD10 (BCD) value for each digit position - Correct?

Seems like a lot of encoding ... for why? The only thing that comes to mind is that the MOD10 forces more transitions (0 & 1) into the data stream for better syncing where there might be (decimal) "0"s in the ID, but I can't figure out why the bit order reversal or the inversion for that matter unless it somehow improves the (in my WA guess) possible checksum/CRC.

New hypothesis: Assuming that your decoding is the correct one for the general case and not a coincidental match, the leading "1" in the transmitter id may be implied with a 5-digit (20bit) actual transmitted sequence and the initial 4 bits (the "2") may be part of the battery status or some other preamble.

Yep, we need more data. I'd send my xmitters to @rg422 , but I'm packing for a Blackbeard's trip.
 
This is interesting, I've never seen a ribbon cable attached this way. It appears the cable was attached during PCB manufacture! Normally they'd be soldered on or would use a connector. How strange!

View attachment 643085

Also: No conformal coating. How disappointing, scubapro.
I know this post is old, but as this thread popped back up, I started reading. The ribbon cable is actually integrated into the Rigid-Flex PCB. The rigid portion is likely FR4, which is common. The flexible portion is generally a couple layers of kapton built around the traces. This type is actually fairly common in some applications. Generally, where space is at a premium. As it's built into the PCB, it can be more reliable than a soldered ribbon cable, and may also be cheaper. While a rigid-flex pcb tends to cost more than a rigid, that can be offset by a reduction in manufacturing steps.

I am surprised about no conformal coating to some extent. I agree with you, it doesn't look like there is any there. Spray on coatings are usually easy to see, and often contain a UV tracer, though the tracer degrades over time. Vacuum deposited coatings are harder to see, but you can usually detect a very fine line separated the coated and uncoated parts. That type of coating is pretty costly though, so I doubt they used that.

It's not unheard of to have uncoated boards in water resistant cases, though. It ultimately depends on the application. I've seen lots of sealed, but uncoated PCBAs in a lot of cases. Coating is most often used on aerospace applications. The rapid temperature changes are the main factor I've seen in coating or not.
 
I didn't post the method as I do not believe it is correct, but as you ask here it is...
View attachment 706365
Data stream with different transmitters IDs would be very helpful. As well as some streams with known battery voltage values.
I agree, seems like an unlikely encoding!
Also, it doesn't look to me like your binary to decimal conversions are all correct. Rather than 1 10 4 3 10 8, I get 8 10 4 24 10 2.
 
I agree, seems like an unlikely encoding!
Also, it doesn't look to me like your binary to decimal conversions are all correct. Rather than 1 10 4 3 10 8, I get 8 10 4 24 10 2.
Each Nibble (4-bits) is reversed
So the after the "Invert" line there should be a "Reverse" line i.e.:

Code:
      Raw: 1011 1010 1101 0011 1010 1110
   Invert: 0100 0101 0010 1100 0101 0001
  Reverse: 0010 1010 0100 0011 1010 1000
  Decimal:    2   10    4    3   10    8
Modulo 10:    2    0    4    3    0    8
 

Back
Top Bottom