Trunk88

[SCPD]

TRUNK88 logs all activity on Motorola 3600bps systems.

Andrew - would you mind updating the Wiki with Trunk88's capabilities? I think that would answer a lot of people's questions.

-rick

 

[slicerwizard]

To be honest, I haven't touched that page, since I felt that an unbiased entry from users was more appropriate. Looking at it now, I see that the TRUNK88 entry already has more in it than the other decoders.

As far as a list of TRUNK88's unique features goes, it could get a bit long. This should be most of them:

- very low CPU and display requirements (can run on 4.77 MHz 808x processors with 25 line displays)
- selectable SVGA display modes (from 12 to 60 lines)
- DAC reprogramming (allows for high intensity backgrounds - great for laptops in direct sunlight)
- user-defined colors for all display elements and backgrounds
- user-defined screen layout
- high contrast mode for monochrome displays
- extended battery life mode for laptops
- autodetects slicer data pin and data polarity
- real time raw OSW display
- real time "S-meter" (decoding accuracy gauge)
- raw OSW logging/playback
- good filtering of bogus events/channels/talkgroups/RID's (e.g. you won't see the SysID showing up as a phantom talkgroup or RID)
- selectable talkgroup display formats, e.g. 11h/17/800017/272 for talkgroup 17
- selectable radio ID display formats, e.g. 7Bh/123/700123 for RID 123
- scrollable talkgroup, radio and channel lists
- searchable talkgroup and radio aliases
- lockable channel list
- selectable 21 or 28 channel diagnostics reporting
- full system activity logging
- system stats gathering (about 45 separate event types are tracked)
- user-defined data autosave interval

programmable alerts for:
- new channel
- new talkgroup
- new radio ID
- BSI start/end
- flagged talkgroup
- emergency event
- diagnotic
- system/network status change
- private calls
- interconnects
- analog comms
- digital comms
- clear comms
- secure comms
- OmniLink roamer activity
- ATB
- system busy
- site trunking / wide area trunking change

- external utilities, inluding Trunker <--> TRUNK88 system file converters

I don't think I'll be pasting that to the wiki.

 

[SCPD]

Thanks Andrew!

As far as a list of TRUNK88's unique features goes, it could get a bit long. This should be most of them:

I'm going to pull out these two ...

- very low CPU and display requirements (can run on 4.77 MHz 808x processors with 25 line displays)
- autodetects slicer data pin and data polarity

Auto-detecting the pin is easy ... just do a lookup based on the 4 bit mask of the MSR. A clever fellow like you can even make it work with 4-level decoder circuits. Signal polarity is easy enough but I deliberately force UniTrunker users to specify the correct polarity. The result is faster acquisition for users roaming the bands looking for new signals to explore. [ Note to self: what I should do is auto-detect and then remember the setting. If the user swaps out radios eg. radio has different polarity - give them a menu option to repeat the auto-detect. ]

Since you've got ample horsepower on modern hardware - consider taking advantage of this to support two, three, or possibly four sessions on the same serial port - each session using a different pin for data (CTS, DSR, DCD, and possibly RI).

-rick

 

[slicerwizard]

Auto-detecting the pin is easy ... just do a lookup based on the 4 bit mask of the MSR.

That only works if there is only one active pin. I don't impose that restriction; I look for the pin that carries useable data.

A clever fellow like you can even make it work with 4-level decoder circuits.

I haven't checked, but it probably does.

Signal polarity is easy enough but I deliberately force UniTrunker users to specify the correct polarity. The result is faster acquisition for users roaming the bands looking for new signals to explore.

Acquisition time is not affected if you test all modes (pin/polarity/protocol) simultaneously. I think it's the way to go if you're planning on supporting more than a couple of protocols.

[ Note to self: what I should do is auto-detect and then remember the setting. If the user swaps out radios eg. radio has different polarity - give them a menu option to repeat the auto-detect. ]

Users roaming the bands can traverse the high/low injection boundary. Retuning a 246T from VHF to UHF toggles the injection from high side to low side; you're forcing that user to change the polarity setting.

Since you've got ample horsepower on modern hardware - consider taking advantage of this to support two, three, or possibly four sessions on the same serial port - each session using a different pin for data (CTS, DSR, DCD, and possibly RI).

The RI pin can't be used for slicer data (at least not on any PC I've tried it on).
I would support multiple sessions by having one app monitor the serial port and then serve timing data to discrete decoder clients. Maybe one day...

 

[SCPD]

That only works if there is only one active pin. I don't impose that restriction; I look for the pin that carries useable data.

Shouldn't there be only one active pin if it's a simple 2-level slicer?

I haven't checked, but it probably does.

Name that tune, uh, function in two lines of C code.

Acquisition time is not affected if you test all modes (pin/polarity/protocol) simultaneously. I think it's the way to go if you're planning on supporting more than a couple of protocols.

Except for MPT1327. I'll keep that in mind - would definitely cut down on the number of trouble-shooting emails. In fact (smacks hand on head) I can do this in about fifteen minutes'.

Users roaming the bands can traverse the high/low injection boundary. Retuning a 246T from VHF to UHF toggles the injection from high side to low side; you're forcing that user to change the polarity setting.

Yes. I've had to manually flip polarity for this very reason. I've also seen cases where the control channel appeared inverted relative to other signals in the same band - turns out it was an "image" from another band.

The RI pin can't be used for slicer data (at least not on any PC I've tried it on).
I would support multiple sessions by having one app monitor the serial port and then serve timing data to discrete decoder clients. Maybe one day...

Awe, c'mon - you didn't have any special plans this weekend!

-rick

 

[slicerwizard]

Shouldn't there be only one active pin if it's a simple 2-level slicer?

One would think so. Tying together two or three output pins shouldn't cause any problems for any decoder and would mean that any pin setting in Trunker, Treport, etc. would work.

Except for MPT1327.

What's the issue with MPT1327?

 

[SCPD]

What's the issue with MPT1327?

FFSK doesn't have a polarity so this issue doesn't apply. Invert an 1800hz sine wave and it's still an 1800 hz sine wave.

Guys, the topic. Otherwise create a TRUNK88 thread.

Oops. Sorry!

-rick

 

[slicerwizard]

I was suggesting that you test for all protocols simultaneously, which would include MPT1327. If I understand you correctly, you're not planning on doing that yet, but you will do auto-polarity. Maybe you already have.

 

[SCPD]

I was suggesting that you test for all protocols simultaneously, which would include MPT1327. If I understand you correctly, you're not planning on doing that yet, but you will do auto-polarity. Maybe you already have.

T4Win and uniTrunker have always run all protocols in parallel. For Motorola, EDACS and P25, I can add an extra instance for inverted polarity. Don't need one for MPT1327.

 

[WayneH]

Split off from another thread....