Trunker88 Decoder Help Needed

[tsalmrsystemtech]

Can anybody give me some help on installing Trunker88. I have been using Unitrunker for a while and I heard that Trunker88 will give me some more decoding information than what the Unitrunker software will.

I am using Windows 7 64 bit and I have a GRE PSR 600 scanner with a PC/IF output for data streaming so I won't need to splice into the discrimmator output.

1. will I need to purchase a sound card or can I use the internal sound card that is built into my motherboard on my computer?

I downloaded the software today and tried running it but reconizes the software but I just can't get it to decode any information.

Thanks for any help on this forum

 

[Forts]

It should work just fine with your onboard sound card. When you start the program, what does it do? Do you see any decoding activity? When it first starts you should see a DOS style box showing what audio card the program is using, then the program itself should open up. There is some tweaking that will be required to get things running, but you should see some sort of activity right out of the box.

 

[tsalmrsystemtech]

yes I got it working and it is decoding just fine. I had to go into my line in and adjust the settings. What other tweaking needs to be done?

Thanks for any input

 

[reconrider8]

when i do it all i get is on the right side it says framing and bad and thats all it says

 

[tsalmrsystemtech]

I had problems at the beginning trying to set up the program. I connected the stereo cable to the headphone output on the scanner and the input to my on-board sound card on my computer.

I had to adjust the sound volume on the scanner so it would put out enough garble so the program could hear the data and had to goto the control panels within windows and adjust the line input on the sound card to allow more garble data so the sound card could hear the data

 

[Comint]

I had problems at the beginning trying to set up the program. I connected the stereo cable to the headphone output on the scanner and the input to my on-board sound card on my computer.

I had to adjust the sound volume on the scanner so it would put out enough garble so the program could hear the data and had to goto the control panels within windows and adjust the line input on the sound card to allow more garble data so the sound card could hear the data

Despite what some people have said, TRUNK88 requires a Discriminator Tap to work correctly, as audio processing after the discriminator stage seriously effects the data stream, so getting it to work with Speaker/Earphone Audio is just a Fluke.

--
Comint

 

[Forts]

Actually.... it's not a fluke. The latest builds of T88 will work with headphone input, and quite well at that.

 

[tsalmrsystemtech]

Despite what some people have said, TRUNK88 requires a Discriminator Tap to work correctly, as audio processing after the discriminator stage seriously effects the data stream, so getting it to work with Speaker/Earphone Audio is just a Fluke.

--
Comint

TRUNK88 is the best program out there. I use to use UNITRUNKER but TRUNK88 gives out way more information on the data stream. I finally got it to work with some adjustments with the sound volume control and the line input on the sound card. So you are wrong you dont need a discriminator tap. All you need is a headphone jack and a good line input on your computer.

I am very happy with the program. Thanks to whoever wrote this program.

 

[slicerwizard]

OK, let's see if my list is up to date - lame, useless and a fluke. Did I miss any?

I am very happy with the program. Thanks to whoever wrote this program.

You're welcome!

 

[tsalmrsystemtech]

OK, let's see if my list is up to date - lame, useless and a fluke. Did I miss any?



You're welcome!

Didn't your mother ever teach you that if you don't have anything good to say than don't say it at all. In reference to slicerwizards comments.

 

[slicerwizard]

Yes, I should say nothing when the man hours that go into a useful feature - a feature that you yourself are taking advantage of - are trivialized as "a fluke".

Despite what some people have said, TRUNK88 requires a Discriminator Tap to work correctly, as audio processing after the discriminator stage seriously effects (sic) the data stream, so getting it to work with Speaker/Earphone Audio is just a Fluke.

That statement is simply not true. Despite the fact that all headphone jack audio consists of significantly distorted/damaged digital audio, when fed from strong local signals, the symbol recovery algorithms built into current versions of TRUNK88 will recover 100% (e.g. no FEC processing required) of 3600 bps datastreams. This applies to the headphone audio jack of many (but not all) scanner models. It would apply to all radios if I was motivated to refine the algorithms, but frankly, with comments like this, I'm not. Calling it "Trunker88" doesn't help either.

And responding to "thanks" with "you're welcome" - what was I thinking?

 

[tsalmrsystemtech]

Trust me I had nothing bad to say about the software inventor. I thought I was defending the the software's creator. My bad. I have only good words about the software. I love it. I seem to have no issues with using the audio output for decoding. It works 99.5 percent of the time correctly and it decodes great. I love this software alot more than Unitrunker. I able albe to decode pages from mobile radios and see what is going on with the data stream before the audio is put out over the radio. I really never understood what you could read from the data stream. Its beautiful.

So I dis-agree too about having to have a discriminator tap to decode the data stream. I am able to get it working properly with some minor tweeks with the output volume and the input line on my internal sound card. Also, the on-board sound card works beautiful. You will not need to go and buy a sound card to make this software work.

I took the word "FLUKE" and mis-inturpitited the wrong way. I say thumbs up to this great piece of software

 

[Comint]

OK, let's see if my list is up to date - lame, useless and a fluke. Did I miss any?

I apologise for the Fluke comment.

I haven't used TRUNK88 since last year, as the systems I previously monitored have moved to TETRA, and MotoTRBO.

I forgot that you had implemented the BitBooster adaptive signal booster in 4.88.

Again, my apologies.

--
Comint

 

[slicerwizard]

Also, the on-board sound card works beautiful. You will not need to go and buy a sound card to make this software work.

That's not necessarily true - after a scanner's audio circuitry takes its best shot at trashing the datastream, some internal sound hardware, or possibly, their drivers, will further filter/mangle the headphone audio to the point where TRUNK88 can't reliably recover data.

However, the inexpensive "3D Audio" USB sound dongles have proven to be very headphone audio friendly, with very little, if any, noticeable additional distortion being added. Their inputs are monaural (tip only), but that shouldn't be an issue with most scanners.

USB 3D Sound Adapter (Color Assorted) - Free Shipping - DealExtreme

Amazon.com: Virtual 5.1-surround USB 2.0 External Sound Card: Computers & Accessories

I forgot that you had implemented the BitBooster adaptive signal booster in 4.88.

Ah, that explains it. No worries then. I'll put you back on the Christmas card list.

 

[DaveH]

Colour me a bit guilty, did not realize TRUNK88 now works on earphone audio.
I tried v4.88 from a PRO-2022 into older HP laptop mic input, getting 90-100%
decode with only scanner volume control tweeking.

Historical note, going back over 10 years, TRUNK88 then called DEMO88
was one of two Moto CC decoders which could actually run on a (!) 16MHz
80386 with 4M RAM; an old Toshiba T5100 "portable" used for portable/
mobile logging (the other was Treport). Trunker bogged the poor thing
down to a standstill.

Dave

 

[slicerwizard]

Historical note, going back over 10 years, TRUNK88 then called DEMO88
was one of two Moto CC decoders which could actually run on a (!) 16MHz
80386 with 4M RAM; an old Toshiba T5100 "portable" used for portable/
mobile logging (the other was Treport). Trunker bogged the poor thing
down to a standstill.

Pretty much every released copy of the DOS version of TRUNK88 will run on a 4.77 MHz 8088 PC - e.g. the original IBM PC and its earliest clones. This is largely due to its self modifying slicer interrupt service routine and its fully unrolled OSW deinterleave code, both written in assembler. The rest of DOS TRUNK88 is written in straight 16 bit (small model) C. Your 386 was overkill.


Treport is all small model 16 bit C, including the slicer ISR, so Treport's CPU needs are somewhat higher than TRUNK88's. Some lower level OSW functions are copied from Trunker, but the slicer ISR doesn't have the superfluous port writes that Trunker has (the ones that cause Trunker to lock up some serial ports)


Trunker is written in C++; its object oriented code pushes the CPU demands up somewhat. Earlier versions of Trunker, which you may have been running on your 386, used far too much CPU because the program's main loop would check the keyboard every time it generated a data bit from the slicer timing data. This meant that the program generated thousands of unnecessary DOS and BIOS calls every second (I'm assuming that the kbhit() and getch() functions called DOS INT 21 functions, which would then call BIOS INT 16 keyboard functions)

At some point, Trunker was modified to only check the keyboard when no slicer data was available, which is how it should've been done all along.

</trivia>

 

[SCPD]

Treport is all small model 16 bit C, including the slicer ISR, so Treport's CPU needs are somewhat higher than TRUNK88's. Some lower level OSW functions are copied from Trunker, but the slicer ISR doesn't have the superfluous port writes that Trunker has (the ones that cause Trunker to lock up some serial ports)

Actually, Treport runs under whichever memory model you choose - including huge if you wanted. The code runs great on 32 bit windows with very little modification. The decision to #include other C files from within a C source file raised an eyebrow. Speaking as a programmer, really?

Trunker is written in C++; its object oriented code pushes the CPU demands up somewhat.

Neal's classes are very lightweight. Not much overhead. The objected oriented structure made it easy for folks like Eric Cottrell to adapt the code to LTR and Passport. The shared code between EDACS and Motorola allowed both to benefit from enhancements.

Earlier versions of Trunker, which you may have been running on your 386, used far too much CPU because the program's main loop would check the keyboard every time it generated a data bit from the slicer timing data. This meant that the program generated thousands of unnecessary DOS and BIOS calls every second (I'm assuming that the kbhit() and getch() functions called DOS INT 21 functions, which would then call BIOS INT 16 keyboard functions)

To be fair, this was a DOS program. Polling the keyboard when there's nothing else to do is perfectly reasonable. It's not like there were other programs in the background.

 

[slicerwizard]

Actually, Treport runs under whichever memory model you choose - including huge if you wanted. The code runs great on 32 bit windows with very little modification.

The Treport version that Dave referred to is the DOS version, and it was built as a small model program.

The decision to #include other C files from within a C source file raised an eyebrow. Speaking as a programmer, really?

Wayne didn't want to use a header file to define the program's global variables, etc., so talk to him, not me.

To be fair, this was a DOS program. Polling the keyboard when there's nothing else to do is perfectly reasonable. It's not like there were other programs in the background.

A program that polls the keyboard whenever a data bit is generated is not a program that polls the keyboard when there is nothing to do. More like the exact opposite.

On anything slower than a fast 486, Trunker would not keep up with the datastream because it was wasting most of its time calling DOS, just as Dave observed.

 

[SCPD]

A program that polls the keyboard whenever a data bit is generated is not a program that polls the keyboard when there is nothing to do. More like the exact opposite.

If the slicer is unplugged, there would be no bits generated and no poll of the keyboard. Yet the program responds to menu navigation. Sorry, I'm too lazy to look back at 10+ year old code. I suspect the performance issue you describe is a bit more subtle.

 

[slicerwizard]

It's not subtle - it's glaring inefficiency.


Actual code from that era:


Trunker/Mtrunker:

while (ef == 0) /* main loop; wait for exit flag to be set (by user via keyboard) */
{
/* check if key has been hit */

if (kbhit() != 0)
{
ch = getch();
...
}

if (i != cpstn)
{
/* process slicer data */
...
}
}


MDT monitor:

while ((kbhit() == 0) && (fobp<29900)) /* main loop; exit on any keystroke */
{
if (i != cpstn)
{
if ( ( fdata & 0x8000) != 0) s = cw1; else s = cw0;

/* add in new number of cycles to clock */
clk += (fdata & 0x7fff);
xct = exc + 0.5 * dt; /* exc is current boundary */
while ( clk >= xct )
{
frame_sync(s);
clk = clk - dt;
}
/* clk now holds new boundary position. update exc slowly... */
/* 0.005 sucks; 0.02 better; 0.06 mayber even better; 0.05 seems pretty good */
exc = exc + 0.020*(clk - exc);

i++;
if( i >buflen) i = 0;
}
}


In both cases, there is at least one kbhit() call per slicer interrupt.


The code should've been written as:

while (exit condition not set)
{
while (i != cpstn)
{
/* process all available slicer data */
...
}

if (kbhit() != 0)
{
/* process keystroke only when no slicer data is available */
...
}
}