ScannerCast: Freeware Streaming With Tags for PSR-500/600

[usswood]

Originally Posted by PeterGV

FIRST of all, thanks for the positive feedback. I definitely appreciate it.

The tags should work, if you're using a supported scanner. Tell me what model scanner you're using, and I'll be able to help you diagnose your problem. If you're using a supported scanner:

a) Check to be sure the right scanner model is selected on the (main) Config tab in ScannerCast;
b) Check to be sure the that you've just selected the wrong COM port;
c) Check to be sure the COM Port speed matches what's set in your scanner (this doesn't apply to the PSR-500/600, which only use a single speed that ScannerCast knows to pre-select).

You can check to see if you're communicating properly with your scanner: The status is shown at the top of ScannerCast's Status tab. You'll either see a message that says something like "NOT COMMUNICATING WITH SCANNER" or "Communicating OK with scanner"...

Peter
K1PGV

OK...thx for the feed back...this morning it wasnt letting me select Com 3 as the port...today it is being nice and letting me...so Alpha tags should be working now!!!

btw im using a PSR-500 sir...

73

[PeterGV]

One thing that somebody pointed out recently, is that you have to be sure ScannerCast is the only application trying to talk to the scanner. You can't have Win500 or ProScan running when you start ScannerCast. Only one application can open a COM port at a time.

I've made this error myself... you should have seen me trying to debug the problem (and how embarassed I was when I realized what I had done) :-)

Peter
K1PGV

[usswood]

Ok, Im using WINAMP and I'm not getting the Alpha Tags...I have them turned on the Program is recieving em... see screenshots.... Can u help me

[PeterGV]

AH! Well, you're more than half-way there, I'd say. You're right... the diagnostic info on the Advanced tab, and the Scanner Connection on the Status tab both indicate you're talking to your scanner.

You ARE sending meta data information (I connected to your feed to check), so it must be just a small problem.

Two things I can suggest:

1) It looks like you have your bit rate set to "96Kbps" -- If that's the case please turn it WAY down. 16Kbps or 24Kbps is really sufficient. Anything else is just wasting bandwidth.

2) Also, please delete the contents of the "Tag Format" box on the ScannerCast "Advanced" tab. Let's get the basic tags to work before we try to format them.

Try that, and see how it looks.

Peter
K1PGV

[usswood]

Originally Posted by PeterGV

AH! Well, you're more than half-way there, I'd say. You're right... the diagnostic info on the Advanced tab, and the Scanner Connection on the Status tab both indicate you're talking to your scanner.

You ARE sending meta data information (I connected to your feed to check), so it must be just a small problem.

Two things I can suggest:

1) It looks like you have your bit rate set to "96Kbps" -- If that's the case please turn it WAY down. 16Kbps or 24Kbps is really sufficient. Anything else is just wasting bandwidth.

2) Also, please delete the contents of the "Tag Format" box on the ScannerCast "Advanced" tab. Let's get the basic tags to work before we try to format them.

Try that, and see how it looks.

Peter
K1PGV

OK..I sure will...thanks again for the help sir

edit:

THAT DID it...the MP3 Bit rate must have been to high...TY!!!!

[PeterGV]

HEY! It's WORKING NOW!!

Good job! It's looking great.

Peter
K1PGV

[AMDXP]

First of all, thank you for making this great program!

My question is, how does the "Tag Format" option work? What are the commands etc?

[PeterGV]

Originally Posted by AMDXP

First of all, thank you for making this great program!

My question is, how does the "Tag Format" option work? What are the commands etc?

You're entirely welcome. I'm glad you're using it and enjoying it.

Tag Format is really pretty simple to use... if I explain it :-)

If you put nothing in the Tag Format box (on the advanced page), ScannerCast will format the tags as follows:

Uniden: SYSTEM GROUP CHANNEL (freq)
GRE Conventional: SLST CONV (freq)
GRE Trunked: TSYS TGRP (freq)

So, if you're using a GRE scanner and the Trunked System name is "Nashua", the frequency is "Police Primary" and the voice frequency is 851.600 by default, ScannerCast will display the following tag:

Nashua Police Primary (DG:851.600)

Note that if you check the "Add frequency to tag" check box (on the config tag) the frequency is automatically appended to that tag. You can't control the format of the frequency... just whether it appears or not.

So far so good? OK. The Tags Format box lets you have some options to format this string. The "replacement commands" that you place in the string are:

%C = Channel, TGRP or CONV channel name
%G = Group, TSYS or SLST name
%S = System name (Uniden only)

Any other characters appear in the tag provided you provide them in the Tag Format box.

So, continuing the example above, let's say you want that Nashua tag to be displayed in Winamp as:

TRS: Nashua -- TalkGroup: Police Primary -- Frequency: (DG:851.600)

(OK, that's a long and pretty ugly tag... but it's an example, right?) You'd specify the following format in the Tag Format box:

TRS: %G -- TalkGroup: %C -- Frequency:

Whenever ScannerCast sees %G in the Tag Format box it replaces it with the current Group/TSYS/SLST. Whenever it sees %C it replaces it with channel or talkgroup name.

Or, let's just say you want the tag displayed to be:

Police Primary, Nashua (DG:851.600)

The contents of the Tag Format box would be:

%C, %G

Play with it, and you should be able to get a good idea for how it works.

The ONLY THING I'll warn you about is that the way the current version of the software works is that you can only format items that you request to be in the tag on the Config page in the Tags Format radio buttons. So, if you want to use %G (for example), you need to be sure you've clicked on "Group + Channel" (Uniden) or "TSYS or SLST name + TGRP/CONV" (GRE).

I'll change the way this works in the next release of ScannerCast.

I hope that's a little more clear now...

Peter
K1PGV

[mtindor]

RE: Tag Format

Thanks for the very clear explanation of how to set custom tags

RE: Reconnect Issues with Scannercast

Peter - I'm used to using Gordon's typical distribution to connect up to the streaming server. When using Scannercast, I find it doesn't do a good job of re-establishing reconnection if the link goes down (either from my end with a network outage or if the remote server shuts down/restarts).

This is rough, especially in the current situation where we aren't receiving notifications for downed feeds.

You may want to look into ways to improve scannercast's ability to detect/reconnect when a connection goes down.

Mike

[PeterGV]

Thanks for the valuable feedback, Mike. I definitely appreciate it. In fact, I noticed the same thing using ScannerCast for my stream, and spent some time at the end of last week and early part of the weekend working on connection re-establishment.

Can you tell me which version of ScannerCast you're using? Because V0.7(607g) should be much better than previous versions in this regard (versions prior to 607f didn't try to re-connect at all... 607f tried to reconnect 10 times and then gave up... 607g tries to re-connect at 5, 10, 20, 40, second intervals, and then every 80 seconds essentially forever).

If you're using 607g and seeing problems, then I clearly have more work to do.

Again, your help reporting this issue is greatly appreciated. It's definitely something that should be fixable... it's just that sometimes these things take a few iterations get working "just right" under real-world conditions,

Peter
K1PGV

[PeterGV]

Actually... to follow-up my own post... In response to Mike's note, I'm looking at the reconnect code YET AGAIN right now. I'm going to add a few more features, and V0.7(607h) should be available later today that is MUCH more robust in re-connecting.

Thanks again Mike!

Peter
K1PGV

[mtindor]

Originally Posted by PeterGV

Again, your help reporting this issue is greatly appreciated. It's definitely something that should be fixable... it's just that sometimes these things take a few iterations get working "just right" under real-world conditions,

Peter
K1PGV

Peter,

Trust me, my comments are in no way criticism. You've created a really nice and useful application that I enjoy. I understand completely about things taking time to work out.

Oh - I AM using 607f - I didn't realize there was a newer version. I will go ahead and update to 607g and will let you know what I encounter over the next few days. And whenever you release the next one i'll be sure to update to that version.

Thanks!

Mike

[PeterGV]

Originally Posted by mtindor

Trust me, my comments are in no way criticism. You've created a really nice and useful application that I enjoy. I understand completely about things taking time to work out.
...

No problem, Mike. I really DO mean it when I say that I rely upon folks like yourself to test the program, and provide feedback. I am, after all, creating the application for the community... it only makes sense to listen to what the community has to say.

UPDATE AVAILABLE:

I've very greatly re-worked the re-connect logic in ScannerCast. The most recent version is V0.7 (607h) is available on the web site right now. It SHOULD be (and I say "should" advisedly) both easy to use (diagnosing connection errors) and pretty close to bullet proof. The way it should work is, if you're able to connect initially (after you click the "Start Broadcast" button), ScannerCast will automatically re-establish the connection.

If, on the other hand, you can't make that initial connection ScannerCast will pop up a dialog box to tell you what went wrong and ask if you want it to continue silently trying to connect with the parameters you've supplied or if you want it to not connect (so you can stop ScannerCast and fix a mistake in the password you filled-in, for example).

I've tested all the cases I can think of at this point... including things like running ScannerCast and once the feed is going, unplugging the network cable for five or ten minutes, and then plugging it back in. It seems to behave properly now.

Of course, you folks will have to tell me how it works for you out in the "real world".

Thanks again -- To Mike and to the others who've sent PMs and emails -- for taking the time to try ScannerCast. Together, I know we can make a great utility.

COMING SOON:

A VERY cool new feature is coming soon to ScannerCast. This will be "Automatic RR feed configuration" -- Basically, you supply your RR username and password, and ScannerCast will look-up all the parameters for your feed from the RR database. If you have multiple RR Live Audio feeds, ScannerCast will allow you to select which one to configure.

What's REALLY cool about this is that if your feed parameters change on RR (different server, port, password, or whatever) ScannerCast will automatically know, and update your parameters for you.

It's just waiting on some work by Lindsay (who seems to be a BIT busy this week) -- Then this feature will be in ScannerCast V0.8!

Peter
K1PGV

[scanmorgan]

I too had not realized there was a new version till i seen it in another post somewhere. V0.7 607h seems pretty solid here. I've been running it for over 24 hours with no problems, and 607f the previous version that i had, usually broke connection within 1 hour. I plan on using ScannerCast fulltime now.

Looks like you've got some great features planned. Thanks for all your hard work!

[DonS]

Originally Posted by PeterGV

Actually, the newer USB drivers still create a virtual COM port. It's just that Win500 (for example) is smart enough to enumerate the various com ports and "know" which one is associated with the GRE scanner.

Not quite. Depending on which FTDI drivers you install (or how you configure them later), there may be NO "virtual COM port" at all. If you see a COM port for the cable in Device Manager, there's a virtual COM port; if you don't, there isn't.

I have two of these cables (1x GRE 30-3290, 1x RS 20-047) attached to my primary PC right now. No COM ports appear in Device Manager. Attempting to open any COM port in the range COM1 - COM256 fails with "error 2" (file not found). Yet the cables (and their drivers) are installed and can be used by software that knows how to talk to the FTDI drivers.

I'm not sure how Don does this, to be honest, but the only ways that *I* know how to do it are a lot of work...

It's fairly easy using the current FTDI drivers, as well as FTDI's documentation. It's FTDI's FT_ListDevices function in their API.

and I'm not really sure what's to be gained. Is there some reason it'shard for the average GRE user to find out the COM port number that corresponds with their scanner's connection? (that's a serious question, not a rhetorical one, in case there's any doubt).

Yes, there's quite a bit to be gained and a reason why it's hard for the average user to find the COM port... The only way to find the COM port assigned by the driver is to either a) look in Device Manager under "Ports (COM & LPT)", looking for a "USB Serial Port" (and hoping you only have one) or b) trying every available COM port that currently exists on your system, looking for the one that "works".

After 8+ years of people using USB-Serial adapters (including the last ~3 where such a device was the only option for the PSR-500), and receiving many, many requests for "how do I know what COM port to use?" or "this scanner came with a USB cable - how do I select 'USB' in your program?", I decided to make Win500 look for the required cable and use it automatically (or prompt you if there are two or more such cables attached).

[PeterGV]

Thanks for taking the time to post, Don, and for being nice enough to share information. We all stand in your shadow when it comes to the great work you've done on software related to GRE scanners. Seriously.

Originally Posted by DonS

Not quite. Depending on which FTDI drivers you install (or how you configure them later), there may be NO "virtual COM port" at all.
...
I have two of these cables (1x GRE 30-3290, 1x RS 20-047) attached to my primary PC right now.

That's certainly interesting, AND it makes my life a lot more difficult. If it's not a COM port with a COMx name, it's not supported by the .NET serial port class. Which means I'll have A LOT of code to re-write.

Well, better to find out now, rather than later.

Can you point me to the driver version that doesn't create a COM port so I can get my code working/tested with it? The most recent version I downloaded DID create a virtual COM port, so I just assumed "they all did that" :-)

Originally Posted by DonS

It's fairly easy using the current FTDI drivers, as well as FTDI's documentation. It's FTDI's FT_ListDevices function in their API.

Ah! Thanks for the pointer to the function! So they provide the library to do this! That's nice... So, you call FT_ListDevices followed by FT_Open. Hmmmm... that would mean I have to talk to the device with their API, which wouldn't be that great. I have to think about this some.

The huge pain comes if you try to use the SetupDiXxxx Windows functions to find the "location" attribute of the bus driver device (for the child device). Then you could use the Device Interface GUID to open the device. But, of course, that means you can't access the device using the .NET serial port class, as I mentioned above.

Originally Posted by DonS

Yes, there's quite a bit to be gained and a reason why it's hard for the average user to find the COM port
...
After 8+ years of people using USB-Serial adapters (including the last ~3 where such a device was the only option for the PSR-500), and receiving many, many requests for "how do I know what COM port to use?" or "this scanner came with a USB cable - how do I select 'USB' in your program?", I decided to make Win500 look for the required cable and use it automatically (or prompt you if there are two or more such cables attached).

OK, I hear that. And given that a major goal of ScannerCast is to be EASY to use for the less "computer savvy" among us, I guess I'm going to have to go the same route.

Oh, my head hurts.

Thanks, Don. I appreciate your insight.

If you want to take the programming discussion off-line, I'm reachable via email my call sign (see below) @arrl.net

Thanks again,

Peter
K1PGV

[DonS]

The FTDI driver package 2.04.16 at: D2XX Direct Drivers contains the "VCP" (virtual COM port) drivers as well as FTDI's "D2XX" drivers (no COM port).

After installing those drivers, and with the cable inserted into a USB port, you should see a "USB Serial Port" in Device Manager, under "Ports (COM & LPT)". For testing, delete that device. Deleting it merely removes the virtual COM port assignment - it doesn't impact the "D2XX" driver installation or the cable's availability through the D2XX drivers.

Also installed with that package are some "ftd2xxxxx.dll" libraries. Those contain the API you'll use.

I used FTD2XX.DLL, binding at runtime via a bunch of calls to Win32's GetProcAddress() (I did it this way so I didn't have to distribute FTDI's DLL with my app, and so that the app won't crash on load if the DLL doesn't exist). I used functions like FT_ListDevices, FT_OpenEx, FT_Read, FT_Write.

If your app is a fully managed .NET application, you may need to write some unmanaged code to interface to the DLL.

There's no need to use any Windows "device" or "USB" APIs. Everything you need is provided in the FTDI DLL. It's fairly well documented, along with code samples, on the FTDI page I included above.

[mtindor]

Peter,

I've got one for ya.... Radio IDs on the PSR500.

Scenario: I scan one trunked system. On that trunked system _most_ public safety agencies communicate regularly on talkgroups such as FIRE DIV 1, EMS DIV 2, LAW DIV 3.

There are several agencies that may be using a talkgroup on a normal basis. Our system has very few talkgroups that are specific to a single agency.

I provide my listeners with information regarding how to tell what agency is speaking based upon how they identify (ex: xxyy where xx = station 74 = Toronto EMS, yy = 73 =ambulance).

Similarly the radio IDs are fairly reliable in telling one what agency is talking based upon their numbering (ex: station 74 can be found on RIDs 74xx and 274xx, station 81 can be found on RIDs 81xx and 281xx).

So, if the RadioID value (if available based upon the user's setting in the PSR/PRO) could be ascertained and then a tag custom variable given to it, I could then do something like:

%G: %R
- where %R is the made up variable for the radio id

which might display:

EMS DIV 1: 7473

What do ya think?

Mike

[PeterGV]

Originally Posted by DonS

The FTDI driver package 2.04.16 at: D2XX Direct Drivers contains the "VCP" (virtual COM port) drivers as well as FTDI's "D2XX" drivers (no COM port).

After installing those drivers, and with the cable inserted into a USB port, you should see a "USB Serial Port" in Device Manager, under "Ports (COM & LPT)". For testing, delete that device. Deleting it merely removes the virtual COM port assignment - it doesn't impact the "D2XX" driver installation or the cable's availability through the D2XX drivers.

Cool, thanks again. I appreciate you being willing to share.

But... just to confirm (sorry to be stupid here)... There are ordinary user scenarios where the shipping FTDI driver package gets installed using the ordinary procedure, and no virtual COM ports are created?

I understand I can disable the VCP device manually. But... there's a scenario where people do that in ordinary use?

Cuz, I'm going to have A LOT of code to change if this is the case. If it's NOT the case, I can find the FTDI virtual COM port number to make life easier for GRE users, but still not have to re-write the core code that talks to the device.

Ugh,

Peter
K1PGV

[PeterGV]

Originally Posted by mtindor

I've got one for ya.... Radio IDs on the PSR500.
...
So, if the RadioID value (if available based upon the user's setting in the PSR/PRO) could be ascertained and then a tag custom variable given to it, I could then do something like:

%G: %R
- where %R is the made up variable for the radio id
...
What do ya think?

Hmmm... I think it's an intriguing idea. Good suggestion, Mike!

Let me take a look at the code over the next day or two, and see what it would entail to reliable snarf Radio IDs from the display info that's returned to me. Grabbing that info is often just a matter of being clever.

I'll post back here in a day or two to report what I find. Now, hmmm... I wonder if I get radio IDs on the ONE trunked system I monitor...

Peter
K1PGV