USA and Canadian callsigns

[andimik]

In https://discord.com/channels/1053804249651359765/1053804250276298895/1164952779656286279 a user has written:

Here are some suggestions for the USA region setting. The PI code is the most important RDS code for DXing FM. Couldn’t the PI code be displayed somewhere when the firmware is set to USA? The callsign or ID displayed for USA radio stations by the beta firmware is very often wrong.
Could we just leave longwave with the European step sizes, 9 kHz instead of 10 kHz, when the firmware is set to USA? The Americas don’t use longwave broadcasting, except for navigational beacons which are 1 kHz apart.
Could we add .2 MHz steps for the FM step size menu item? FM stations are .2 MHz apart in the Americas. 88.1, 88.3, 88.5, 88.7, 88.9, 89.1, etc. It would save time tuning when in the Americans.

The 200 kHz steps seem to make much sense.

Is there any place free to display the PI code and the call sign?

Longwave steps of 10 kHz are not useful, he is right.

[MCelliotG]

There is no space for both PI and callsign and frankly I'm surprised the user wants PI because these have no use at all in the USA and RBDS. They only use the hex codes in order these to be converted to call signs since RBDS does not use any block to display this info directly like it should. Since the firmware has a separate setting for deemphasis, they can select Europe and 75 for deemph. What would be useful in my opinion would be to change the setting Region to Data System and select RDS ans RBDS instead of Europe and USA. This would be more accurate as none of these systems is exclusive to the respective regions

[Shortwavedave1]

I agree that it would be useful to change the setting Region to Data System and select RDS or RBDS instead of Europe or USA. Band step size and FM deemphasis could be independent from the Data System setting. FM band step size could be user selected at 50/100/200 kHz in the FM settings menu. MW band step size could be user selected at 9kHz/10 kHz in the AM Settings menu. Longwave band step size would be 9kHz and shortwave band step size would be 5kHz.

However, I disagree with the idea that PI codes aren't useful in North America where RBDS is being used. I’m in the USA and I’m using the PI code to DX with. DJDevo is in Canada and is using the PI code too. I use it to quickly identify what radio station I'm listening too. The PI code is far more accurate at identifying the correct radio station than the firmware’s ID callsign look up is. For U.S. radio stations, the ID is accurate about 60% of the time, while the PI code is accurate about 95% of the time. And as DJDevo said, the ID feature doesn't work at all for Canadian radio stations.

I have the location of every FM radio station in the U.S. and Canada stored as waypoints in a mapping and hiking app on my smartphone. The PI code is stored in the waypoint information, allowing me to determine the distance and bearing of the radio station I'm listening too in just a few seconds. When radio stations are using a non-standard PI code, about 5% of the time, I just update my database to reflect the non-standard PI code that the radio station is actually using. This makes my waypoint database and its PI codes 99% accurate in identifying the radio station I'm listening to.

I also disagree with the idea that there is no space for both PI and callsign. The ID (callsign) is displayed on the main FM window when set to USA. Why is displaying ID a second time on the USA RDS page so important? Why can't we just leave the USA RDS page as it is in Europe displaying the PI code. That way no additional space is used at all and North Americans with RBDS can see both the ID and the PI code without changing any settings. Also, as far as I can tell, the ECC box on the USA RDS page is not displaying any useful information in North America. If so, the ID box could simply replace ECC box on the USA RDS page, rather than the PI box, which is being displayed and used in North America.

Right now, if I want to identify a radio station that has been misidentified by the ID box, I have to go through the following: long push, scroll to RDS settings, push the tuning knob in, scroll to region, push the tunning knob in, scroll to Europe, short push, short push. I don’t even worry about the deemphasis setting, because that would involve several more steps. Meanwhile, my 1000-mile e-skip DX catch has faded into oblivion without being correctly identified because the firmware does not retain RDS information when it switches from USA to Europe. So, I then have to hope that the station will fade in again after the setting has been changed to Europe, so I can see the PI code and ID it.

[Shortwavedave1]

Also, when the FM signal is weak (and sometimes even on strong signals) the ID box will display multiple different callsigns one after the other making it difficult to know which one is the correct callsign. I have seen it display 6 different callsigns when I was only receiving one weak signal. Many of these callsigns start with the letter K (meaning the radio station is west of the Mississippi river) even though I am on the east coast where FM callsigns all start with the letter W. On stronger signals it will settle on the correct callsign about 60 percent of the time. On weak signals it flips from one callsign to another with the correct callsign displayed along with false callsigns. Many of the 40% incorrect callsigns on strong signals start with the letter K as well. For example, WMZQ is KCQK. While I have seen spurious PI codes when the FM signal is weak, spurious information in the PI code box is much less frequent making it easier to use than ID box.

[MCelliotG]

That's true, however the correct way for users and especially DXers is to contact these stations to assign a correct PI code, otherwise we have to adapt the code with a vast number of exceptions, and that is not easy when we all live in Europe. We need all the help we can get, especially with the Canadian and Mexican call signs. Call signs have been implemented in the firmware to help non European users and be as close to the American RBDS standard as possible. If you ask my opinion, I disagree with the call sign thing anyway, it's not useful for DXers, only for regular users. You can see both now, but we need reports to add exceptions if you need the correct callsigns to be implemented.

[PE5PVB]

Default stepsize can now be set to 50, 100 or 200kHz.
RDS USA now shows both PI and callsign.

[MCelliotG]

Nice fitting, I didn't think about having smaller letters. Let's hope now it covers our American DXers demands.

[Shortwavedave1]

Nice work. I downloaded the latest beta and the multiple callsign issue seems to have been fixed. It is helpful to see the PI and the callsign together at the same time. I'm willing to help, if I can, with the ID box callsign issues, although I agree that DXers like me are more interested in the PI box because it is unfiltered and unchanged while ID box will always make some mistakes.

Here is some information on USA PI codes:

https://nabpilot.org/fm-broadcasters-need-to-make-sure-that-rds-pi-codes-are-properly-set/
https://picodes.nrscstandards.org/
https://picodes.nrscstandards.org/fs_pi_codes_allocated.html?
https://picodes.nrscstandards.org/pi_codes_allocated.html
https://picodes.nrscstandards.org/audit.html

Here is some information on Canadian PI codes:

https://ised-isde.canada.ca/site/spectrum-management-telecommunications/en/licences-and-certificates/broadcasting/program-information-codes-radio-broadcasting-stations
https://www.dxinfocentre.com/Call_Signs_Sangean.htm

This website has PI codes for some radio stations in North American countries including Mexico:

https://db.wtfda.org/

Would a list of the radio stations in my area that have bad ID box callsigns help you figure out what is going wrong with these IDs? I could provide the correct callsign, the incorrect callsign from the ID box and the PI code used, if that would be helpful. Most of the time these stations are broadcasting the correct PI code according to the National Association of Broadcasters (NAB), but are still showing bad callsigns in the ID box.

Thanks for making a 200kHz band step an option for FM. My radio tunes twice as fast and every turn of the knob brings a new station instead of static.

I want to make one more pitch for a 9kHz step size on LW when the radio is set to USA. I can pick up European and African LW broadcasts here on the US east coast, but I can never remember which frequencies to check on because I am not used to 9kHz steps. So having these frequencies available by turning the tuning knob is useful, but I have to change the radio's setting to Europe to get 9kHz steps on LW. As was said earlier, 10 kHz steps on longwave are not useful, while 9kHz steps are useful, even in North America.

[Shortwavedave1]

Three more links on USA PI codes:

https://www.fmsystems-inc.com/rds-pi-code-formula-station-callsigns/
https://db.wtfda.org/rds1.html
https://db.wtfda.org/rds2.html

[PE5PVB]

Please help me out. I have the idea that the callsign converters most of the time doesn't work because the radiostations do not apply the conversion correct. How can I know the exact callsign from the PI code?

Should I use the list on https://picodes.nrscstandards.org/ ?

[Shortwavedave1]

Your last update to the firmware fixed the multiple callsign problem, but about 20% of callsigns displayed are still bad. I checked some online PI code converters and got the same results. If you can use a database to generate the callsigns, like I do, then you can solve most of the bad callsign problem for USA radio stations.

There are two lists, a full-service list and a translator list:

https://picodes.nrscstandards.org/fs_pi_codes_allocated.html
https://picodes.nrscstandards.org/pi_codes_allocated.html

You can simply cut and paste both lists into one excel spreadsheet. I select paste special and paste text in excel. Make sure column B in your excel spreadsheet is formatted as text first, otherwise excel will screwup the PI codes and your data will be corrupt. I have attached a spreadsheet in the hopes that you can use it. If you are able to use this data to generate callsigns, you could also use it to generate the city and state of the radio station. Now that would really be cool if you could fine the space on the screen to do it!

If you cannot use a database then it becomes a question of the formula being used to generate the callsign and I am not sure that any formula can do that accurately. We could try, but it probably will not be easy.

USA PI Codes.xlsx

[PE5PVB]

Thank you so much for the xlsx file. I found a way to add the whole list to the radio and do a check on PI code and frequency. I first need to find doubles in this list and sort them out, then convert them to an array and then make a script to find the right callsign and state with the already known PI code and frequency. To be continued....

[Shortwavedave1]

Excellent!

The spreadsheet I gave you is what the NAB thinks the PI code is or what the NAB wants the PI code to be, I am not sure exactly. I also use PI codes from the WTFDA FM DATABASE (https://db.wtfda.org/) for my smartphone database because the FM Database of PI codes is crowd sourced from DXer's actual observations. So, I use the FM Database PI codes first and fill in what is missing with the NAB data that is in spreadsheet attached earlier. The FM Database contains PI codes for other countries in North America as well. I also correct the PI codes in my area using my observations from the TEF radio.

There are often several unrelated radio stations in different parts of the USA (and perhaps elsewhere in North America) using the same PI code. My smartphone database uses my GPS coordinates and sorts the results by their distance from me, but that won’t work for your firmware. If you use the PI code and frequency together, as the radio station identifier, it will help your code choose the correct callsign when different radio stations use the same PI code, but operate on different frequencies. Not sure what we can do about instances where two different radio stations have the same PI code and frequency, but that is probably rare. Radio stations that have translators on the same frequency will use the same PI code and frequency, but the callsigns are similar. For example, KHPR v. KHPR-FM1. We could just delete data that has an FM1 or FM2, etc. Also, keep in mind that some radio networks use one PI code for the whole network. So, if they have 2 full-service radio stations and 3 translators, they may all be using the same PI code, usually the callsign of the flagship station. At least in this case the radio stations are related so the information might be useful. None the less, there may be some unrelated radio stations using the same frequency and PI code and that might produce the wrong callsign in some cases. No solution will ever be perfect, but hopefully using a database will be an improvement. Although, maybe we should continue to use your existing formula for converting PI codes that aren't in the database.

If the correct callsign can be identified, then USA and Canadian licensing data becomes available too. So, you could display the power in kilowatts and antenna height above sea level, as well as city and state, if you have the screen space and the right dataset.

[PE5PVB]

I successfully added the comparison table to the software. It will check the combination of the PI and the frequency, if found, it will show the callsign. If not found it will calculate the callsign adding a ?.

I used the supplied Excel document. If you have a better list, please help me, by creating a complete list with 3 columns. In the first one the PI code, 2nd column the frequency and 3th column the callsign. I have no memory left for the state.

Please do not mix up US and Canadian stations. Use a seperate excel file for Canadian stations.

[Shortwavedave1]

Let's just start with a USA dataset first. We can work on Canada later.

I agree those are the columns the dataset needs. However, let me think about the dataset you should use a little before I create it for you. My phone app doesn't have to be exact because my phone will list all the stations that have a certain PI code in either database. The beta firmware is more exacting and needs to pick the best match. I have only been using PI codes for 4 months now because I got my first TEF radio in May. So, I am not an expert on them by any means.

Your PI code converter is working much better since the multiple callsign issue was fixed. There are probably some situations where it may be better at choosing a PI code than my dataset would be. Is there a way to use your PI code converter formula as a backup when the PI code is not found in the database?

Here is an example of why a PI code might not be in the database. WMET AM on 1160 kHz has a translator on 103.1 MHz. It uses a PI code of 74D3. Which your PI converter formula correctly decodes as WMET. However, WMET is on AM, not FM. It's FM translator's callsign is W276DT and according to the NAB list it's PI code should be D5F2. In this case, the actual PI code for the translator was in the WTFDA FM DATABASE, but there will be similar situations where the actual PI code the radio station is using will not be in this database. There are a lot of translators in the USA and they often will use the PI code for the parent radio station's callsign instead of the translator's callsign. Many of these parent stations are on AM. Should we include the NAB list of translator callsigns at all since so many will be using their parent radio station's callsign? Perhaps we should only use the NAB list of full-service radio stations because that list is probably much more accurate. Perhaps translator PI code data should just come from the WTFDA FM DATABASE or your converter formula because it is more likely to be what the radio station is actually using than the NAB suggested PI code for the translator.

I will have to do a new dataset just for you because I add an * to the callsign to indicate digital broadcasts and a plus sign for construction permits and two minus signs to indicate a station is off the air. I will have to make a data set for you without those additions to the callsign and without the construction permits or foreign data being included.

There is a lot to think about before we change the way the radio decodes PI codes. I feel a little uncomfortable at the idea of changing everything based on my limited knowledge knowing that you will have to do the actual work because I can't say for certain that my dataset will give better results. I think it will, but that's not the same. A little more research may be needed. The percentage of errors I have cited are off the top of my head estimates and may not be entirely accurate. I could look at all the radio stations in my receiving area and get the real percentage of errors, at least in my area, for your converter formula now that the multiple callsign problem has been fixed. That would give us a baseline to test against to see if using a dataset would actually be better than using your converter formula. If it is, then the percentage of errors in my area should be lower when using the dataset. A hybrid of the two methods may yield the best results if using both methods is feasible.

[PE5PVB]

I found a way to have the states as well, using SPIFFS. Please test out the latest beta.

[Shortwavedave1]

Very nice work. The NAB dataset correctly identified over 60 radio stations at my home location. The NAB dataset appears to be the gold standard for the USA. There were 3 radio stations using their network's PI code instead of the NAB assigned code. All 3 were correctly decoded using your original formula method. So, I found no bad callsigns here at my home in suburban Washington, DC. The hybrid solution works great! The question mark lets us know that the callsign is not the assigned callsign of the transmitter, but probably a network callsign. It also lets of know that there is a possibility that the network callsign may not have been decoded correctly. Not sure if the WTFDA data is needed. I will take the radio out to a mountain top to DX a spot where hundreds of radio stations can be recieved. It will be interesting to see if I can idenify some bad callsigns.

I will do some research on what needs to be done to decode Canadian callsigns.

[PE5PVB]

Thanks. I also wonder about the state identification, is that correct too?
BTW. I found a few stations with shared PI and freq. but from two different states. Only the first one in the database will be used. You can't have it all ;-)

[PE5PVB]

And if you have any missing information, just add them to the .CSV files.

[Shortwavedave1]

The 3 radio stations that were using network PI codes don't display state. The state in the NAB dataset is the state of license, which is not always the same as the state the transmitter is in, but this only happens in areas near state boundries. I have not seen any mistakes concerning the displayed state other than that issue. I would assume the state in the NAB's dataset is from the FCC's database.

[PE5PVB]

I love to see it in action, maybe you can make a Youtube video?

BTW. Is there a forum around where US FM-dx'ers chat?

[Shortwavedave1]

OK, I made a trip to the mountains and was able to log a lot of different radio stations and I did identify some problems with bad callsigns. The RDS lookup is now over 95% accurate, but it still has some issues. Some radio stations were not identified by NAB dataset in the firmware even though they were in the excel spreadsheet that I provided. I have attached a CSV file that has been deduplicated, that is there are no doubles of PI code and frequency when used together as an id. So, no data should be deleted from this file. Most PI/Frequency duplicates in the NAB dataset are for the same callsign and can be deleted by deleting any entry with an -FM1, -FM2, etc. Once, these same-callsign entries are deduplicated, there are only 2 real duplicates (stations with the same PI code and frequency, but different callsigns). So, only two radio stations in Oregon have been left out of this CSV dataset. There 21,530 diferent radio station PI codes in this NAB CSV file. If you have a different number of radio stations in the firmware, then maybe something got deleted that shouldn’t have been deleted.

I could also add more PI codes from other sources such as the WTFDA FM Database, but I haven't done that yet. If the WTFDA FM Database has a diferent PI code for a radio station than the NAB dataset, it could be added to the CSV file so long as the PI code/frequency combination is not already in the NAB dataset. That way the firmware would have a second chance to id the radio station if the NAB dataset doesn't have the PI code being displayed by the radio station. This would reduce the number of radio stations that the firmware would have to use the old PI code formula method on and therefore reduce the number of errors and question marks.

I will try making a video with my phone and will attach it here when done. You can put it on Youtube if you like.

Here is the WTFDA forum url: https://forums.wtfda.org/
USAPIcodes.csv

[Shortwavedave1]

Thanks, it helps to see the actual CSV files you use. I have figured out how to change the PI code to a decimal. So, I can make these files now and either provided them to you, or, if you like, upload them directly to the URL you provided. I see that you just broke the spreadsheet data I gave you up in to 10 CSV files, without deleting anything. I did find a radio station that wasn't in the database, but it wasn't in spread sheet I provided either. It was in the NAB database. So, not sure why it was left out. In other cases, it seems that the NAB had the wrong PI code or the radio station was using a nonstandard PI code.

There is a problem you might be able to fix with the old formula method we are now using as a backup. The formula generates nonsense callsigns sometimes. These nonsense callsigns are identified by having a funny second character. Here are some examples (where the underscore is a skinny rectangular box, instead of a letter or a number):

KtBM from 99B5 should be WJZ
KyLL from 70EC should be WKSI
KyQZ from 807C should be WQPO
K_AJ from D3B0 should probably be just a ? because the formula can’t handle this type of PI code
K_BR from D12E should probably be just a ? because the formula can’t handle this type of PI code
K_XP from D382 should probably be just a ? because the formula can’t handle this type of PI code

These last 3 PI codes are of the type that begins with a D. They are usually used by translators and there is no formula for them. Any PI code that is not in the database and starts with a D should be shown as a ? only.

I would like to replace the 10 CSV files you are currently using with 10 new CSV files in the same format. The new files would contain Canadian PI codes and PI codes from the WTFDA FM database when its PI code is different from the PI code that is in the existing database. I would like to include Mexican PI codes too since there are some in the WTFDA FM database. I have used the formula from the CBC spreadsheet to calculate a callsign for all of Canada’s full power radio stations, except the CBC radio network. I also have the PI codes for the 4 CBC networks. These PI codes could just be added to the database with each one being paired with all the available frequencies. Instead of the callsign, the CBC stations would display the network. CBC1 and CBC2 for the English networks and CBCF1 and CBCF2 for the French networks. I would be adding about 2000 new PI codes. So, about 200 more entries for each CSV file. I would also delete the 408 duplicate entries in the current files. There will be no duplicates of PI code and frequency in all the data I provide. Let me know if this is OK before I do the work. I could put the new data in separate files if you really need it that way, but would prefer not to.

[MCelliotG]

Why are the some stations so indifferent in using the correct PI so it corresponds to their actual callsign?
WKSI should use A7EC
WQPO should use A87C
So, is it impossible for a listener to mail these stations and simply ask them to correct their PI codes?
In reverse DB30 should be any of these K224FN, W206CE, K215DJ, W276BJ, W262AL, W264DB, K288BQ. They can only be added to the formula with case exceptions.

[Shortwavedave1]

RDS started in Europe and was slow to catch on in North America. I don't think most radio stations in the USA have given PI codes much thought because most radio stations in the USA don't use AF, even when they are part of a network or have multiple radio stations with the same programing. And most stations are not part of a network and don’t care about AF. Some are just relaying AM stations that can’t use AF. Many others are now broadcasting an HD digital signal in addition to their analog signal. So, there is a lot going on. One would have to find out the name and email of the station engineer and hope that they are familiar with PI codes and are willing to take the time to fix them when it is probably of no importance to the engineer. And why would an engineer listen to me when the NAB has a different PI code in its database?

So yes, it is impossible for a listener to mail all these stations and simply ask them to correct their PI codes because the listeners don’t know what that the correct PI code should be. Nor do the engineers. I have spent far more time than probably almost any listener in this country looking in to PI codes and I don’t know when a code is correct or incorrect because I don’t know the formula that is used. All I can do is check the code against the PI code converter websites and see what they say. When I do that for the PI code that WQPO is using, 807C, it comes back as WQPO on these converter sites. When I do that for the PI code that you say WQPO should be using, A87C, it comes back as WQPO on these converter sites. Same thing with WKSI. How am I to know which code is correct or incorrect? The NAB database and all 3 websites identify WJZ’s PI code as 99B5. https://db.wtfda.org/rds1.html or https://radio.feralfox.net/tools/rds.php or https://caseymediallc.com/rds.

Basically, the formula we are using identifies the station correctly only half the time. So, we would have to mail tens of thousands of radio stations to fix the problem and most of them would probably ignore us. If the mountain won't come to Muhammad, then Muhammad must go to the mountain. Is it possible to change our formula so that it works the way these websites do? Is it possible for our formula to just display a question mark when the PI code starts with the letter D? If it is too much work to fix these problems or if they can’t be fixed, I understand. However, an email campaign is not going to fix the problem anytime soon.

[Shortwavedave1]

If there is an easy way to make the formula work with PI codes that start with a D that would be great, but I am assuming there isn't.

[Shortwavedave1]

If we can't make our formula work the same way as the websites, could we just display a question mark only, instead of a nonsense callsign.

[PE5PVB]

If you can send me the new csv or excel files, I can modify the PI code to the right format.

I'll modify the software, so when one character is not uppercase A-Z, ID will show only a ?

[PE5PVB]

Done

[Shortwavedave1]

I will provide you with one CSV file containing the NAB data, plus the WTFDA data and the Canadian data from the CBC spreadsheet. The file will also contain Mexican PI codes from the WTFDA. If I detect anything on my TEF that is not covered by these data sources I will add it too. That way when I do the video of the Washington, DC FM band scan for you, all the RDS stations will have the correct state and there will be no question marks. I will include the following columns in this CSV file: the PI Code, the PI Code in decimal, the frequency multiplied by 100, the callsign and state or province to be displayed on the radio. You can tell what country the data is from by the callsign. Callsigns that begin with a W or a K are in the USA. Callsigns that begin with a C or a V are in Canada. Callsigns that begin with an X are in Mexico. Perhaps you could create the ECC country code from that.

If I am formatting the PI Codes in decimal correctly, then maybe I can make the 10 individual CSV files next time, if it will save you the work. I say this because we are using a database for our PI codes that will need to be updated at least once a year and ideally probably should be updated every six months. Callsigns and translators change quickly in North America. There will always be erroneous data that needs to be fixed and new data provided by the TEF radio itself. And there are about 400 low power stations in Canada. The CBC spreadsheet contains a formula for the low power stations that works, but I cannot reproduce the rows in a way that decodes all the low power stations at once. If I figure out how to decode these all together, instead of one at a time, we will want to add these PI codes to the database as well.

There is also the possibility of adding more countries to the dataset, like Central America and the Caribbean. I vacation in the U.S. Virgin Islands and would like to have PI codes for the British Virgin Islands and other nearby islands. So, we may want to upload these PI codes too, in the future. This data would come from the WTFDA dataset like the Mexican data does.

By the way, one can bypass the database and just use the old formula by pushing the tuning knob in and tuning up or down from the radio station's frequency by .01 MHz. This could be useful in cases like WMET's FM translator where they are using the relayed station's callsign instead of the actual transmitters’ callsign. The database will provide the translator's callsign, while the old formula will provide the name of the relayed station, in this case WMET. Also, I will change the frequency of the second radio station in situations where there are two radio stations using the same PI code/frequency combination, instead of deleting the radio station with the duplicate PI code/frequency combination. For example, 105.11 instead of 105.1. There are only two stations that I know of like that, but there may be more when Mexico is added. So, tuning up or down by .01 MHz may provide additional information.

[Shortwavedave1]

OK, I see you are rounding the frequency now, so I will delete the two duplicate PI Code/frequency combinations and I will delete any new duplicates of this kind when the Mexico data is added.

[PE5PVB]

I can make an exception on the rounding for Callsign discovery.

[Shortwavedave1]

OK, that would be great. DXers always want more information. So, I will leave the duplicates in, but will add .01 MHz to the second radio station's frequency.

[PE5PVB]

When do you have the files ready? I want to close up to a release candidate.

[Shortwavedave1]

I could have it done by the end of the day today USA time, but would like another day to spot check the results. Let me know if you need it all done today, if not I will take another day to double check everything and provide the file by the end of the day tomorrow.

Also, would like to make a couple of suggestions regarding .2 MHz step size and the length of both the AM and FM bands for the Americas. These suggestions aren't that important, but if there is a quick fix it would be nice.

The USA uses 1710 kHz for some low power radio stations. I listen to a 10-watt AM radio station from New Jersey on that frequency. There is a 10,000-watt station on 1700 kHz in New York city. So, I tune up to 1712 kHz to get a better signal because of the interference from the more powerful station on 1700 kHz. So, it would be nice if the MW band could end at 1720 instead of 1700 kHz.

There are no radio stations on 87.7 in the Americas, but there are a number of radio stations on 87.75 MHz. The reason for this is that 87.75 was the analog frequency of TV channel 6. There were some low power TV stations that were using TV channel 6 to broadcast audio on FM. These radio stations were grandfathered in to the FM dial when analog TV was turned off in the USA. Could we start the FM band at 87.75 for the .2 MHz step setting? The next step to 87.9 would be less than .2 MHz, but all the following steps would be .2 MHz.

The .2 MHz setting ends with 108 MHz, instead of 107.9 MHz If one tunes to 108 MHz, it can can change the .2 MHz steps from odd to even. For example, 88.2, 88.4, 88.6, etc. Could we delete the stop on 108 MHz for FM when using .2 MHz steps?

[PE5PVB]

I modified the stepsize to your preferences. I can wait another day for the CSV files. I want to create a release candidate this weekend.

[Shortwavedave1]

Thanks.

I have one more idea. Could we get a setting for the sensitivity of the auto tuning? Maybe, 1 through 10. DXers tend to want a more sensitive auto tune, while people looking for a static free station want a less sensitive auto tune. Auto tuning is still missing stations that it shouldn't miss on MW/SW. It skips over clear and listenable signals on MW and especially on SW. I figured out that if the radio is in auto mode when I switch bands to shortwave, I can use auto tuning on shortwave. I find this feature to be very useful because SW is a very long band and it does not have as many radio stations as it used to. Searching for radio stations 5 kHz at a time on SW is painstakingly slow. So, it would be nice if one could auto tune the entire shortwave band without missing many listenable radio stations. Or, perhaps the auto tune sensitivity could be tied to the squelch level.

[PE5PVB]

I added the scan sensitivity setting for FM as well. I can't do anything to improve the scan on SW, because if I tweak this a little more it will stop at static as well. Currently noise and frequency offset is measured. You can adjust the noise threshold in the menu.

[Shortwavedave1]

Thanks again. I look forward to trying the new release.

Here is the CSV file of PI codes. All USA PI codes were updated. Canadain full power stations have been added, including CBC network stations. CBC network stations have a question mark instead of a state. PI codes were also added from the WTFDA FM Database when they were different from the NAB PI codes. And Mexican PI codes from the FM Database were also added. There are no duplicate PI code/Frequency combinations. You can tell what country the data is from by the callsign. Callsigns that begin with a W or a K are in the USA. Callsigns that begin with a C or a V are in Canada. Callsigns that begin with an X are in Mexico. This dataset should make the callsign lookup about 99 percent accurate in the USA. Many of the problems seen during my trip to the mountains have been fixed by this new data.

rdspi.csv

[PE5PVB]

Thanks. Just added it to the RC1 beta version. Please test.

[Shortwavedave1]

The callsign lookup is working great here in the USA. I will ask about how well the Canadian callsign lookup is working in the general discussion, but assume that it is also working well. If it is working well, you might want to change the RDS region setting to be North America v Europe, rather than USA v Europe.

Thanks again for the scan sensitivity setting. It is definetly better now, but it still isn’t sensitive enough when set to 10. Could we extend this setting to 15? As a DXer, I am looking for weak signals and I don’t care about static stops, unless the majority of the stops are static. I expect static. 15 should be the setting where 50% of the stops are static, because the alternative is listening to a lot more static as I manual tune the entire SW band to find the BBC signal that auto scan couldn’t find. The scan sensitivity seems to get lower with increasing frequency on shortwave. So, a wide open 15 setting would be nice when scanning the upper end of the SW band. SW signals are usually weaker in the Americas than they are in Europe, Asia and Africa.

A wide open 15 setting would also be great for those of us who have squelch knobs. The squelch knob is better at setting the scan sensitivity because it has over 100 different levels that I can scroll through just by turning the knob. And the level is displayed on my screen alongside the signal strength. So, I know what signals auto tune will stop on when I use it. For example, when the squelch is set to 99, scan will only stop at signals that are 100 dBf or more. When the squelch is set to 79, scan will only stop at signals that are 80 dBf or more and so on. I will always want to set to scan sensitivity to the absolute maximum possible, so that I can use the squelch to determine how much sensitivity to use when auto scanning for very weak signals. I don’t know what to expect when I use the default scan sensitivity setting because it will often miss the strongest signal on MW in my area, but stop on weaker ones. If I use the 1 setting, it will miss the most powerful MW signal in my area every single time, but will still stop on weaker stations. I can easily exclude all signals except this one powerful signal when scanning with squelch knob.

When you say noise is measured, I assume you mean signal to noise ratio. I don’t even know what frequency offset is. I also don’t know what you mean when you say I can adjust the noise threshold in the menu. Unfortunately, I don’t know what many of the settings do. I just adjust them and play it by ear. If there is a manual somewhere explaining all the settings, I would love to read it. If there isn’t one, I would be willing to help write one.

One more thing. Could we make the PI code for the USA region a little more legible somehow. I have 20/20 vision but still have to squint to read it, especially when I am outdoors in the daylight. Maybe we could put a little more space between the characters of the PI code or use a different font. Maybe a bold font. I don’t know but something is needed.

Also, I have noticed that the correct PI code is often displayed for a long time before the callsign on weak signals. So, perhaps there is an opportunity to make callsign display a little quicker on these weak signals.

[PE5PVB]

I updated the sensitivity to 15. Text USA will be changed to America in the final version. I can't change the font for the PI code, there is not enough space on the screen and in the memory to do this. For now I will close this discussion. If you have any updates in the future, please let me know.

About speed. It can take some time to look through the tables. I can't improve that. Maybe in the future we can divide it to MHz level, currently a CSV file is created for every 2 MHz. So 91-93MHz is one file.

[Shortwavedave1]

OK, that is great. Thanks so much. Your firmware updates have made the TEF a much better radio! Especially on LW/MW/SW. I am looking forward to scanning the SW band.

About Speed. It is pretty quick, usually 1 or 2 seconds after the PI code appears. However, when the signal is marginal, it may show the correct PI code for several minutes before identifying the callsign.

[PE5PVB]

@Shortwavedave1 Can you provide the same list with this information?

• Frequency
• Station name
• rds pi
• rds ps
• erp power
• location name
• lat, lon
• optionally also regional name (if this is a bigger station network)

[Shortwavedave1]

The last list had call sign, frequency, state/province and RDS PI.

I can use government licensing data to add city, erp power, antenna elevation (above sea level), transmitter lat and lon for the U.S. and Canada.  I can add city for Mexican radio stations. 

[PE5PVB]

Thanks. It's for our webserver enviroment. If you can send me a Excel document will all this info, should be great.

[Shortwavedave1]

I don't know what you mean when you say websever environment. I am guessing it is for something different from the firmware. Will take a few days.