Data Slicer and unitrunker

[shajoe44]

Can a data slicer be used with Unitrunker and if so how do I set it up. I am using Windows XP.

Thanks

 

[SCPD]

Yes it can ... but the driver isn't very stable. You may see a BSOD (blue screen of death) as the Windows kernel tosses it's cookies. I haven't run this mode in over six months so bear with me.

Make sure the decoder is "offline".

For signal source, select the appropriate pin and port combination for your computer and slicer. Use the up/down arrow keys to step though the possible choices. Examples:

DTR on COM1
CTS on COM2

... etc. ...

You are limited to standard PC serial ports that map to IRQ 3 and IRQ 4. That generally means COM1, COM2, COM3 or COM4. Beware that P25 decoding does not work with this option - but the others should do fine.

The biggest complaint (aside from crashing) is from folks using slicers powered by the serial port - they don't seem to work.

If your PC crashes ... make sure you disconnect the slicer before rebooting. The next time you run UniTrunker, you can take the decoder offline (again) and set it back to some other sound input.

-rick

 

[shajoe44]

Guess I will have to try it with an audio cable. I can't get anything by using my data slicer. I do not see a DTR or CTS option under configure signal. All I see is Sound Input 0 and Default Sound Input. Also my slicer is powered by the computer so it seems that is the wrong kind of slicer anyway. I am use to using Trunker.

Thanks for your help and I will keep trying after I get the audio cable.

 

[GroundLoop]

Any support for a data slicer that samples and packs the bits into a serial stream?
No DTR or CTS, just serial bytes containing the bit samples.

 

[GroundLoop]

Oh, wow.. 2005. Sorry.

 

[SCPD]

Oh, wow.. 2005. Sorry.

This thread was for the Retro version of the program. In the new program I could support such a thing.

At one point I had a design for a slicer that used a GAL16V8 to insert start/stop bits to feed the RxD pin directly. In other words, it was a lever slicer and a time slicer (each bit represents a fixed amount of time).

What you suggest I'd have to call a symbol slicer since each bit represents an actual symbol.

 

[GroundLoop]

If I'm understanding correctly, this device:
RS-232 Interface
most accurately represents the signal I would tap and convert in the MaxTrac.

I would take the digital "high speed" discriminator data bit from the radio, run it into an Atmel processor (like their PIC), sample it at some fixed interval, and pack those samples into bytes for 8-N-1 serial over a COM port. So yes, a time slicer. I don't know if the MaxTrac internally does 4-level or 2-level slicing before it sends the 5v digital signal into its CPU.

If it helps, I can also oversample them and synchronize, if the bitrate is constant and known (for Mot Type II, for example)

Really, whatever works best for UniTrunker. Something that doesn't involve an analog audio input, or a bit-banged CTS/RTS line would be best. Open to any ideas, and willing to experiment.

 

[SCPD]

The time slicer design assumes the bits are sampled at the serial port's baud rate. In other words, the baud rate generator also clocks the register that latches the incoming data. You could sample at the baud rate (and replace two bits with start/stop bits) or 80% of the baud rate. It really does not matter. Higher baud rate means greater temporal resolution.

Baud rate selection: 19200 would comfortably handle Motorola. 57600 would handle EDACS.

If you want to get fancy, you could support multiple inputs and interleave the bit steams. 115200 could easily handle stereo bit streams.

The program won't require the sample rate to be an integer multiple of the target protocol's baud rate.

 

[GroundLoop]

This sounds awesome.. is there already an input mode for that on UniTrunker?
I can code up the adapter tonight, but I don't know how to configure UniTrunker to read the serial stream that way.

If the bit rate doesn't have to match the protocol's baud rate, or synchronize start bits, that's really easy. Just sample, and stuff bits.

You want first (temporal) sample in MSB?

 

[GroundLoop]

I'm looking at the digital input to the MaxTrac CPU, and it looks like the cycles are around 1mS?

I see three (short) cycles in 3.05mS
I was expecting... faster?

Here's the analog signal at the J601 jumper as well.

 

[SCPD]

If I read the top image right, the time delta between the solid and dotted trace is 1.67 ms. The waveform crosses zero six times during this delta to represent 010101. 1.67 ms divided by 6 symbols is 0.278333 ms. The reciprocal of that is 3593 which closely matches the 3600 bps rate for Mororola trunking.

Bottom image - you've selected mid symbol in first and last symbols of a three symbol sequence - 101. The waveform crosses zero twice so the interval spans two symbol periods. The scope shows 544us. The time for two symbols is 555 us. Close enough.

Looks good to me.

 

[GroundLoop]

Ah, I see.. you're counting zero crossings. Seems like I found the right pin, then.

One option is to 'digest' these bits in the Arduino and simulate a Uniden or GRE PSR-600 CCh receiver. Then it would work 'as is' with the software.

Really though, backing up a bit.. I think it would be awesome for UniTrunker to define its OWN preferred serial data protocol. Something that sends PC->Radio tuning commands and includes custom display data (TGID name, etc).
Likewise a Radio->UniTrunker Control Channel data stream that leaves as much as possible to the software decoder for flexibility. High speed bit sampling off a discriminator comparator seems like a win.

The serial format you described above -- bit sampled at the UART rate.. does UniTrunker (.22) support this today, or is it a wishlist item?

 

[GroundLoop]

I'm way outside my ken here, but is there any reading material on how to go from the raw (zero-crossing) timing (above) to the 'M36' messages in the GRE CCDump stream?

I know UniTrunker does this internally, but I'm curious to know if this could be externalized to make the data more compact.

p119 of the PSR-500 User Manual describes the format
http://www.greamerica.com/download/manuals/PSR-500v1.3_Manual.pdf

It's not clear how the GRE protocol communicates the bit-errors or confidence. I know this is a problem with Unidens, which seem to have a pretty dirty data stream.

 

[SCPD]

High speed bit sampling off a discriminator comparator seems like a win.

I agree. It isn't supported but could be easily added.

is there any reading material on how to go from the raw (zero-crossing) timing (above) to the 'M36' messages in the GRE CCDump stream?

Look at the Dumper source code found in the original Trunker source (vintage 2001).

IIt's not clear how the GRE protocol communicates the bit-errors or confidence. I know this is a problem with Unidens, which seem to have a pretty dirty data stream.

They flag bad data with a trailing "E" or "Err". The Unidens are not any more dirty. They just don't tell you which frames failed the checksum.

 

[GroundLoop]

Cool! If you are willing to add UniTrunker support, I will write the Arduino code, post it here, and write up instructions on how to tap a MaxTrac first, and possibly a discriminator audio stream if I can get the A/D running fast enough. Arduino Uno boards are < US$30 from Amazon and others, so this is cheaper than any RS-232 bit slicer.

I have to think other folks would also like to free up the Audio inputs for recording the call, and expanding the number of monitored systems beyond one or two.

I would very much like to add interleaved support for multiple feeds in a single 115200bps serial stream.

I'm a big fan of SIMPLE, so... no header/framing works fine, just bits sampled at a known period.

It would be good to allow the bit sampling rate to be specified, so that someone could run a low sampling rate (16,000) on a faster serial stream (115,200). The other reason is that some boards may not be able to sample at a clean interval of the RS-232 bit clock, if they run off different timebases. Does this complicate things? It seems like lock-step would cause some jitter.

What would receiver setup look like? Do you need to know which interleaved stream is which?

RS-232 speed: 115,200bps
Sampling rate: 16,000bps
Interleaved Streams: 2
Interleave Slot: 1

RS-232 speed: 115,200bps
Sampling rate: 16,000bps
Interleaved Streams: 2
Interleave Slot: 2

--- or ---

RS-232 Speed: 115,200
Sampling rate: 16,000
Interleaved: 2

 

[SCPD]

Cool! If you are willing to add UniTrunker support, I will write the Arduino code, post it here

Consider it done for the next release.

Tying the sample rate to the baud rate simplified the design for a PLD based design (eg. PAL/GAL). See this thread.

http://forums.radioreference.com/tr...-lowpass-filter-unitrunker-design-thread.html

Reducing the sample rate provides no benefit. This isn't your father's 8250 UART. They're FIFO buffered. A 16 deep buffer would hold 128 samples.

Some microcontrollers' A/D converters are interrupt driven - one sample per interrupt. This may be a problem at high sample rates.

Back to your configuration question ...

If you standardize on a fixed baud rate, 8 data bits (msb first) and 1 stop bit - you've also simplified the configuration for the end user. Fewer choices = fewer mistakes. Each receiver would need it's "signal source" device configured.

Here's another idea. If the microcontroller has an edge triggered input and clock register, you can sample the level once on each edge transition and count the number of clocks since the last transition; ship the RLL coded deltas over the serial line. That's exactly how the old DOS programs worked.

 

[scottbailey]

I'm way outside my ken here, but is there any reading material on how to go from the raw (zero-crossing) timing (above) to the 'M36' messages in the GRE CCDump stream?

I know UniTrunker does this internally, but I'm curious to know if this could be externalized to make the data more compact.

p119 of the PSR-500 User Manual describes the format
http://www.greamerica.com/download/manuals/PSR-500v1.3_Manual.pdf

It's not clear how the GRE protocol communicates the bit-errors or confidence. I know this is a problem with Unidens, which seem to have a pretty dirty data stream.

Rick is right to look at the source for Dumper, which you can find here, but that's not going to immediately make the theory readily apparent.

Here are some additional places that might be a better starting point (keep in mind some of these pertain to original Type I; the theory is the same, but some specifics have changed):

• http://www.decodesystems.com/mottrunk.txt
• UsenetPost - Trunker
• Patent #4055832 - error correcting
• Patent #4159469 - basic transmission protocols

I would recommend against implementing the OSW decoding within the embedded system - at least for purposes of feeding data to an application - just, at most, do the error correction and output a raw data stream for the application to consume. The OSWs vary a little bit between generations, and you're mainly thinking in the context of a Motorola 3600 system - which is only one of the system types that Unitrunker supports. Also keep in mind that Unitrunker is but one application that will consume this data, and that trunking (of whatever format) is not necessarily the only use.

 

[GroundLoop]

Thanks for the helpful links! I will study up on how the decoding works, mostly for curiosity.
And Mot 3600 only because, hey, San Diego is slathered in it.

Also keep in mind that Unitrunker is but one application that will consume this data, and that trunking (of whatever format) is not necessarily the only use.

That's a very good point. The simpler and more raw the data, the more protocols can use the same format or adapter.

So, a fixed-interval bitstream seems like the lowest common denominator.
I'll rig something up and generate some sample data files for test.

This is just meant to move the traffic off the sound card (freeing up the sound card) with a very inexpensive Discriminator-to-USB interface.

 

[jcardani]

Groundloop, Unitrunker (Rick), and Scottbailey:

How about using the Arduino as a 2level/4level demodulator? (Scott just PM'ed me about this but I believe Rick had that idea using the Arduino before)

Basically using the Arduino's ADC to sample the discriminator audio and output symbols or dibits to the RS232 port. Rick and I were brainstorming about ways to code 4 level about a year ago. Rick should be able to provide ideas on how to code the demodulator.

This can be used as a front end to Unitrunker, DMR Decode, and other programs.

Groundloop, would you be interested in coding this for the Arduino?

thanks,

Joe

 

[GroundLoop]

I'm up for anything, but I'm still wrapping my head around 4-level FSK.

For 2-level, it seems I have the discriminator audio available, and the comparator output of the same in the MaxTrac. If you oversample the signal, it seems you could feed the audio straight to a digital input on the Arduino and forget the A/D. For conditioning, you would have to get rid of the DC bias on the signal above, scale it to around 0-5v, and then treat it as digital and oversample.

The Arduino A/D is a strange thing.. the default prescale gives it a 10-bit sample rate around 9600 Hz (16MHz Arduino). We don't need all that resolution, so we can bump the prescaler down quite a bit, and get something around 75 kHz as a sample rate. That's a lot of A/D... enough to oversample a 9600Hz signal about eight times.

The A/D on the prebuilt Arduino UNO boards has a selectable reference of 5v or 1.1v.

If we sample the discriminator audio with the A/D and send raw samples over USB, then the Arduino essentially becomes a USB audio recorder. Not going to happen with 115,200bps serial, though some people have done it in short bursts ("Arduino DAQ"). The Arduino could take the A/D samples and run a software threshold comparator to turn it into 0/1, of course.

So what processing on the Arduino is appropriate? The common RTS/DTR Data Slicers seem to just track the signal with a single bit, leaving the computer to time the zero crossings.
I'd like to get away from 'timing' and just have the time implied in the continuous bitstream.. that's the discussion above.

A 4-level interface seems to just bin the signal into one of four voltage ranges.. a two-bit A/D?
I haven't messed with 4-level slicers, but is it just that simple?
If so, we could pack four samples into a serial byte and be on our way.

If we use the 1.1v reference for A/D, is it reasonable to think that most discriminator audio could be scaled down using a resistor divider? Is that something within reach of most people?