New protocol: Motorola Type II SmartZone

[ilyacodes]

Just curious on your thoughts about potentially adding support for Motorola Type II? Is this an effort you would be onboard with, if it were proposed as a PR?

I'm mostly interested in contributing to the decoding - once we get CC messages demodulated into binary messages. But I'd be up to look into the demodulation as well... in theory it's just normal FSK so should be relatively easy to demodulate.

I mostly just don't want to start on it if you oppose adding it to DSD-FME for whatever reason(s). I know other projects already support it (boatbod op25, etc), so I can certainly work on it there instead, if so.

[lwvmobile]

Well, I'm not opposed to the idea by any means, if you do have the inclination to add support for it. I do have a couple of recommendations/caveats, however.

1. Let the smoke settle on the improvements done for EDACS and let's make sure that all that code is working well and gets merged correctly into its final place and nothing is randomly broken in other areas.

2. Make it in a new branch that is created from result of the finalized merged version of above, be it in audio_work once that's merged, or I may choose to make a new branch a successor to the 'audio work' branch and let that be a last resort fall back for some users if they don't like the work I'm currently doing with audio filtering, etc.

3. I have no more access to Motorola Type II Smartnet/Smartzone. Duke Energy transitioned to Harris P25, and as far as I know, I have no other local or remote systems (that may change if I make any discoveries, etc) So, in other words, I wouldn't be able to contribute hardly anything to testing and development on that.

4. I'm not going to be doing nightly windows builds for you on that. Total PITA. You'll have to make sure its all working and building on your own on that one. I suggest the VM route, or alternatively, get an old laptop or workstation or something and put Linux Mint on it. Its so much easier than dealing with Cygwin.

[lwvmobile]

BTW, If you do do any more work, go ahead and put it in audio_work_dev now (either Moto II or EDACS), going to prune some of these surplus branches and push what we got so far into audio_work, and let any new stuff go into audio_work_dev instead, its kind of a pain to merge three branches together for the nightly stuff, so just going to commit and fix later if broken, but I think its fine enough for now, no major breakages noted as of right now.

[ilyacodes]

That all sounds good. Especially re: 4 - thank you so much for that! I know it was a lot of work on your part to produce Windows builds and was incredibly welcoming to a newcomer to the project to have so much support when I came along and wanted to contribute.

I've dug out my gigantic old Ubuntu laptop to try and get things working ahead of looking at Type II (be it contributing to op25 or adding to DSD-FME)... I'll let you know if I run into any issues, but that's my first step before setting up any VMs.

I do suspect it may make more sense for me to contribute more to the existing op25 boatbod implementation, since they already have the demodulation in place, just need more opcode investigation. That would save some duplication of efforts.

[lwvmobile]

I don't suppose you could use SDR++ to record a bit of wav file and upload it for inspection by any chance. It doesn't have to be very long, perhaps just a one minute sample of the control channel. I can probably go ahead and do an initial setup for it, if nothing else.

[lwvmobile]

BTW, if you do make some sample wav files, make sure to change the audio settings in SDR++ to 36000, that may be optimal for Type II and its 3600 bps signalling rate.

[ilyacodes]

I still need to get the recordings, sorry for that delay.

I did get my first PR up today for op25, which is probably the direction I'm going to go to avoid duplicating efforts.

[ilyacodes]

Here's a recording, let me know if you want any further ones - I can get them easily.

audio_854562500Hz_11-09-03_13-04-2024.zip

[lwvmobile]

Just FYI, If you do decide you want to do some work on this, I deleted the typeII dev branch and just made a patch for it instead and added it to the patch folder to be applied later on. I went and did a test rebase merge with it, and it was kind of a pain, it wanted to stop every few commits upstream for manual resolution, and I made a few mistakes in the test rebase, so I figured it would be easier to have a patch to apply at a later date to the dev branch and just work on it that way instead.

[ilyacodes]

I've been poking around with this, thanks for making it!

In particular I've tried experimenting with it to see if I can use it to receive ISWs - I documented my efforts here. Still having trouble, when I adjust the sync word to 1010101010 to match what I've demodulated using another tool, it doesn't seem to lock (or maybe has some other failure mode) where I don't end up getting the data printed to the screen.

It does receive a CC just fine though, which is awesome.

[lwvmobile]

Sounds good so far. Did you say you had some level of successful decoding of Type II OSW with DSD-FME, or just have it synchronizing? Keep in mind, with the super short frame sync pattern, DSD-FME may let in a lot of garbage with the demodulator in the current state.

[ilyacodes]

For the OSWs so far I'm just getting them printed as-is, without decoding (basically what your patch already did). I will try decoding soon - I took a diversion to try and demodulate and decode ISWs since that's something that neither DSD-FME nor op25 support currently.

Is there any particular trick to setting up the sync pattern? This is the sync pattern in Universal Radio Hacker:

But when I set that up in DSD-FME (just by changing the one you already set up for OSWs), it seems to only let in garbage, not my usable signals.

[lwvmobile]

Is the sync pattern 10-bits or 8-bits long for ISW? If its 10, then you'll need to use a strncmp with synctest10 and see if you can find the 10-bit pattern in there instead. Just a guess. I really hate the way frame sync and demodulation are handled as-is, one day, needs to be fixed big time.

[ilyacodes]

I've tried both - I'll keep experimenting.

[lwvmobile]

you might also try increasing the t_max value to 10 or so, see if that works

[ilyacodes]

Okay, I'm able to sporadically catch and decode ISWs in DSD-FME now. I'll keep fiddling with it to see how to catch them more consistently, since right now it catches maybe 1 in 10.