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!

Being 38khz signal, you can use a sound card if you have a good one.
Good idea. My first thought was that it wouldn't work without an analog front-end to amplify the signal and filter power line noise (I see a lot of that on my scope, but it has good filtering to eliminate it). My second thought was that higher sample rates on sound cards are meant for better fidelity at audio frequencies - more samples per cycle - not so much to increase the audio frequency response, so I wouldn't be at all surprised to find the sound card's analog front end response above 20kHz to fall off a cliff. But then, why not try anyway? Not having a tank means dragging my compressor in to my computer, so maybe I'll do that just for the hell of it. Who knows, might work, right?

@Robbyg, I ooked at the waveform of the mp3 file you posted. Is that a recording of the squawk that can be heard in the video, or a sound card capture from the coil? Either way, I'm not seeing the pulses in that file that show up so clearly on the scope, so I'm guessing there's either alot of filtering going on (speaker, mic) or aliasing (44.1kHz sample rate).

When you look at the Pelagic signal structure their is a first section of the pulse that remains the same and I think its safe to assume that is the serial number and then the last 1/4 of the pulse have a lot of shifting happening. I assume that is the last tones for the least significant digits of the Air Pressure.
I think you're right. I've gone a step further with my scope - I've used my phone to record a video of the pulse burst then (laboriously) extracted frames from the video that show the trace. It's messy and noisy, and I can't get a clean snap of the whole thing in a single frame, but it was enough to see that the first 2/3 are constant and the remaining 1/3 changes.

This is typically a frequency range used for IR modulation or Acoustic gear.
Something clicked when I noticed this comment today. So here's what I've got so far:

1. Modulation is CW, with pulses of constant length, and short or long pauses between pulses.
2. Low-level encoding (pulses to 1's and 0's) is NEC code used for some IR remotes. Long pause after a pulse is a "1"; short pause after a pulse is "0" (or vice versa).
3. Data protocol is still unknown, but each burst is about 60 bits, and the s/n must be in the first 2/3 and the pressure in the final 1/3.

Whether there is any encryption going on is still an open question, but the fact that the beginning never changes argues against it.
 
What I see at the beginning is 0010000001101... or 1101111110010 ... depending on whether it's literally NEC bit-coding or the inverse. I have two transmitters and this part is the same for both, so maybe there's a constant header, or preamble, or manufacturer id. I can't get a clear enough capture of the whole thing yet.
 
Perhaps if we put together a simple test protocol for people to follow, we could gather a few sample readings from different transmitters and compare, this way we could probably decipher the different parts. Eg if first part doesn’t change between transmitters, second and third only then most likely it’s manufacturer id etc.
Don’t have any transmitters myself but have friends who do
 
Really nice find with it being the NEC IR remote code! It makes sense that they would have repurposed encoder / decoder chips available at the time these were first developed.

Regarding the sound cards 96khz / 192khz sample rate cards for sure have higher frequency capability, the intent is to capture the higher overtones of instruments etc. The filtering only needs to avoid aliasing so rolling off at half the sample rate. The front end gain should be plenty without pre-amp, just a small loop antenna close to the transmitter, especially since we don't care about range to capture a sample transmissions. mp3 will be no good, must be a wav or other raw format.
 
No new data yet.

@Pkishino, good idea, but right now I don't know an easy way. It would be dead easy for anyone with a storage scope or logic analyser, but that's probably not a whole lot of folks.

@dm9876, it doesn't seem to be literally the NEC code, but just using the low-level bit encoding: long pause / short pause for "0" or "1" or vice versa. I got excited thinking it could be that cheap and easy (use an IR decoder chip), but the datasheets I looked at all have minimum number of carrier cycles per pulse and minimum delay between pulses, in order for the chip to detect properly. The AI pulses are too short (not enough carrier cycles) and much too close together for these chips to work.

About sound card sample rate - I don't think they're made to record (or reproduce) ultarsonics. Sampling at 44.1 kHz (CD) the high end of audible is barely below the Nyquist limit so those frequency components are really poorly represented. So higher overtones are inaudible or sound crappy. 48 kHz (DVD) is only a slight improvement. 192 kHz provides about 9 samples per cycle for higher audible frequencies, which can reproduce their shape quite nicely, therefore better fidelity. It also lets the designer build a flat response out to 22 - 25 kHz, and roll off beyond that.

Of course if I get up the energy to drag in the compressor I'll find out for sure. Maybe modern sound cards are doing things I don't expect!
 
uw:
it doesn't seem to be literally the NEC code

in that case I recommend to check out manchester encoding. it looks not too dissimilar to what you described with the NEC code. Manchester Encoding in Computer Network - GeeksforGeeks

regarding the sound card, for sure a 44.1 or 48khz unit is no help and they are the most common, so you would what to check what you have, but at least some of the 96 or 192 khz ones are good for it as I have seen other projects where people have used them for VLF radio experimentation.

eg see here: Receiving VLF with a PC sound card, Miniwhip Antenna and SAQrx

and here: X-Fi modifications

Regards
Dean
 
I still haven't got my transmitter into the same room as my computer to try recording with the sound card, but I have verified that even though the card samples up to 192 ksps, the frequency response drops off beyond 22 kHz (down -1.7 dB at 22 kHz, -9.0 dB at 23 kHz, -24 dB at 24 kHz and basically no response beyond that). Maybe a more pro or studio grade card would have a wider frequency response, but this is all I've got.

@dm9876, about the NEC code: I should have been clearer - it does look just like the NEC IR encoding scheme, just not identical timing (length of pulses, lenght of pauses between pulses). It's clearly not using the NEC IR protocol, and obviously couldn't use the NEC IR data representation. But translating pulses/pauses to 1's and 0's I'd bet is the same.

I've been thinking about the sampling rate. It may just be that lower frequency response of more basic sound cards, like in most laptops or tablets, would work anyway, maybe even better. The basic idea of AM reception is to amplify the weak signal, filter and rectify to extract the envelope of the waveform. You want to supress the 38 kHz carrier anyway. The signal we're interested in (the train of pulses) is much lower frequency - about 1 kHz or less. I don't see why sampling at even a really low rate wouldn't show the pulses - since at a lower sample rate the sound card has to be filtering out frequencies above the Nyquist limit. It would be like taking advantage of the sound card's low frequency resonse to extract the signal (Well, it's an idea anyway. Unfortunately for me it still means getting my transmitter near my desktop, and I'm out of time to continue looking at this.

Maybe someone feels like wrapping a bunch of turns of wire around their transmitter, connecting it to the mic input of their computer and seeing what can be seen? I'd suggest lots of turns for a stronger signal, and if you don't already have software, try Audacity which is a free open source audio recording / editing suite. You can use it to not only look at the waveform but digitally "amplify" the signal to bring it up out of the background in case it's really weak. I think it's worth trying as an experiment. If it works you'd expect to hear a chirp every 5 seconds like in the video posted by @Robbyg way back earlier in this thread.

Wish I had more time, but I'll keep my eye out
 
uw:
What I see at the beginning is 0010000001101... or 1101111110010 ... depending on whether it's literally NEC bit-coding or the inverse. I have two transmitters and this part is the same for both, so maybe there's a constant header, or preamble, or manufacturer id. I can't get a clear enough capture of the whole thing yet.
Man I have not been here for months and I come back and see that some of you guys have been interested in carrying it further. I had taken some snap shots from the spectrum analyzer and it showed the first five or six header bits remained the same and the last 8 or so bits changing with the pressure drop.

I did a check on some desktop photo folders and cannot find the pictures, I will see if they are on a thumb drive that I might have plugged into the analyzer.

I hope I can find them as setting this back up the and doing it again is going to be very time consuming.
 
I'm interested in what you all are working on. I wanted to add that shearwater's swift transmitter was processed through the FCC recently and has more info available. The swift is backwards compatible so presumably info found here applies to the older MH8A transmitters.
 

Back
Top Bottom