[chirp_users] Icom IC-2100H, Excel spreadsheet, csv files, chirp-next-20240111-win64
GM, all, Thanks for this bit of testing. I intend to do my best to keep track of this topic, because I need to be clear in my docs to the ARES group.
As an erstwhile software engineer and programmer, I expect that the record reading routine instantiates a record structure populated with defaults, then proceeds to read the csv, filling in any valid data found. That would seem to create only valid complete records.
I've been using chirp-next, so that accounts for some of my success. I see that I am not using URCALL,RPT1CALL,RPT2CALL,DVCODE but I have ,,,, at the end of each line. I am using MS Office 2010, which I have been using for years, though I see that there have been updates to it that I have accepted.
1. In the spreadsheet, I CLEAR all unused cells...I don't just leave them "apparently" empty. I Save As csv file. (all these files are available upon request)
1a. I open an img file from the 2100H, then IMPORT the csv (it IS an option, even if the popup says it isn't recommended), it appears that the img is updated SOMEWHAT correctly. Some memory lines are left blank, and I dont't see why...the csv lines look fine to me. If chirp sees too many commas in a row, does it get tired of processing nothing, and skip the rest of the line? Because I have this
4,EROCK4,147.465000,,,,,,23,NN,23,Tone->Tone,FM,5.00,,50W,EAST ROCK VOICE ONLY,,,,
and it is skipped.
2. If I choose to OPEN the csv file, the result is the same...I have blank lines in the csv file tab in chirp.
3. I then filled (spreadsheet) Offset, rToneFreq, cToneFreq with valid data, even though those fields are not used. For example, if a channel is simplex, there is no offset. If no tone option is specified, no tone value is needed. Hence CLEARing the fields in the spreadsheet, rather than leaving them "blank". If I don't CLEAR them, I get spaces twixt commas. I don't know how chirp handles those.
4,EROCK4,147.465000,,0.600000,,88.5,88.5,23,NN,23,Tone->Tone,FM,5.00,,50W,EAST ROCK VOICE ONLY,,,,
3a. I then opened the csv in chirp. The import stopped at line 23, but I suspect that is because the rest of the channels don't match the 2100H freq range (154.9..162.475). I'll check the specs. BUT now all the formerly blank lines are filled.
3b. I copied lines 1..23 from the csv tab to lines 1..23 in the ing tab, and it seems that all lines are correct. *** Unsed fields (see #3 above) are showing blank, as expected. I havna had a chance to load it into a 2100H and then read it, to see how that looks. BUT it seems that chirp is making some decisions I don't understand. I havna run into this before, because I tend to fill all fields, whether used or not, with defaults.
4. I checked the 2100H specs. The RX is listed as 136�174 MHz, BUT *Guaranteed 144�148 MHz only.
Nonetheless, the deleted lines contain what seems to me to be valid data.
73 Rich NE1EE The Dusty Key On the banks of the Piscataqua
Hi Rich
I've probably missed something. Why do you need to use CSV files at all? If it's multiple radio types, I believe you can import the .img file from one radio into a different radio model. The only reason I see to use csv files is if you need to print it to paper.
On 11/01/2024 14:44 GMT Rich NE1EE thedustykey@imaginarian.org wrote:
GM, all, Thanks for this bit of testing. I intend to do my best to keep track of this topic, because I need to be clear in my docs to the ARES group.
Nigel A. Gunn, ///shoulders.outwards.resolutions tel +1-937-971-0366 Amateur Radio G8IFF W8IFF and GMRS WRBV701, e-mail nigel@ngunn.net www http://www.ngunn.net
On 2024-01-11 10:25:, Nigel A. Gunn G8IFF/W8IFF wrote:
Hi Rich
I've probably missed something. Why do you need to use CSV files at all? If it's multiple radio types, I believe you can import the .img file from one radio into a different radio model. The only reason I see to use csv files is if you need to print it to paper.
I am working with folks who find it easier to use the spreadsheet, because they are not chirp users. This really will not be done often, so after this pass is over, and the radios are updated with the same image, we won't be using the spreadsheet or csv files very often.
I use the image files myself, but for others who prefer to use the spreadsheet or csv file, the spreadsheet is definitely much easier for them. Then the only way to get to the images files in chirp is via the csv file.
But that is beside the issue...there seem to be problems with processing csv files...?
~R~
I don't think there is a problem assuming your spreadsheet has the correct number of columns, correctly named and in the required order.
Other software neither names the columns as Chirp does nor contains the required number of columns in the correct order.
On 11/01/2024 16:00 GMT Rich NE1EE thedustykey@imaginarian.org wrote:
On 2024-01-11 10:25:, Nigel A. Gunn G8IFF/W8IFF wrote:
Hi Rich
I've probably missed something. Why do you need to use CSV files at all? If it's multiple radio types, I believe you can import the .img file from one radio into a different radio model. The only reason I see to use csv files is if you need to print it to paper.
I am working with folks who find it easier to use the spreadsheet, because they are not chirp users. This really will not be done often, so after this pass is over, and the radios are updated with the same image, we won't be using the spreadsheet or csv files very often.
I use the image files myself, but for others who prefer to use the spreadsheet or csv file, the spreadsheet is definitely much easier for them. Then the only way to get to the images files in chirp is via the csv file.
But that is beside the issue...there seem to be problems with processing csv files...?
~R~
chirp_users mailing list chirp_users@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_users This message was sent to Nigel Gunn, W8IFF at nigel@ngunn.net To unsubscribe, send an email to chirp_users-unsubscribe@intrepid.danplanet.com To report this email as off-topic, please email chirp_users-owner@intrepid.danplanet.com Searchable archive: https://www.mail-archive.com/chirp_users@intrepid.danplanet.com
Nigel A. Gunn, ///shoulders.outwards.resolutions tel +1-937-971-0366 Amateur Radio G8IFF W8IFF and GMRS WRBV701, e-mail nigel@ngunn.net www http://www.ngunn.net
.img files are radio specific. You can not use a .img file from an Icom ID-880H with a Baofeng UV5R for instance.
To move data from radio type a to radio type b, you export the data to a .csv file(which has no radio specific data unlike a .img file). Then open up an .img file for radio b and import the .csv file to replace the freq/repeater data and then upload it to radio b.
So if you are working with a group that has various makes & models of radios, a .CSV file is how you exchange the freq/repeater data.
Lyle W9LRG
On 1/11/24 10:00, Rich NE1EE wrote:
On 2024-01-11 10:25:, Nigel A. Gunn G8IFF/W8IFF wrote:
Hi Rich
I've probably missed something. Why do you need to use CSV files at all? If it's multiple radio types, I believe you can import the .img file from one radio into a different radio model. The only reason I see to use csv files is if you need to print it to paper.
I am working with folks who find it easier to use the spreadsheet, because they are not chirp users. This really will not be done often, so after this pass is over, and the radios are updated with the same image, we won't be using the spreadsheet or csv files very often.
I use the image files myself, but for others who prefer to use the spreadsheet or csv file, the spreadsheet is definitely much easier for them. Then the only way to get to the images files in chirp is via the csv file.
But that is beside the issue...there seem to be problems with processing csv files...?
~R~
chirp_users mailing list chirp_users@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_users This message was sent to Lyle at lyle@lcrcomputer.net To unsubscribe, send an email to chirp_users-unsubscribe@intrepid.danplanet.com To report this email as off-topic, please email chirp_users-owner@intrepid.danplanet.com Searchable archive: https://www.mail-archive.com/chirp_users@intrepid.danplanet.com
Lyle. NO. You save the one radio as an .img file and directly inport that .img file into the next radio. No .csv needed.
So if you are working with a group that has various makes & models of radios, a .CSV file is how you exchange the freq/repeater data.
Lyle W9LRG
On 1/11/24 10:00, Rich NE1EE wrote:
On 2024-01-11 10:25:, Nigel A. Gunn G8IFF/W8IFF wrote:
Hi Rich
I've probably missed something. Why do you need to use CSV files at all? If it's multiple radio types, I believe you can import the .img file from one radio into a different radio model. The only reason I see to use csv files is if you need to print it to paper.
So if you are working with a group that has various makes & models of radios, a .CSV file is how you exchange the freq/repeater data.
Lyle W9LRG
On 1/11/24 10:00, Rich NE1EE wrote:
On 2024-01-11 10:25:, Nigel A. Gunn G8IFF/W8IFF wrote:
Hi Rich
I've probably missed something. Why do you need to use CSV files at all? If it's multiple radio types, I believe you can import the .img file from one radio into a different radio model. The only reason I see to use csv files is if you need to print it to paper.
On 11/01/2024 17:07 GMT Lyle Giese lyle@lcrcomputer.net wrote:
To move data from radio type a to radio type b, you export the data to a .csv file(which has no radio specific data unlike a .img file). Then open up an .img file for radio b and import the .csv file to replace the freq/repeater data and then upload it to radio b.
On Thu, Jan 11, 2024 at 12:09 PM Lyle Giese lyle@lcrcomputer.net wrote:
.img files are radio specific. You can not use a .img file from an Icom ID-880H with a Baofeng UV5R for instance.
You sure can. I do this all the time to transfer memories between my source image (which happens to be from a 12 year old UV-5R) to test and use in many of my CHIRP supported handheld and mobile radios.
To move data from radio type a to radio type b, you export the data to a .csv file(which has no radio specific data unlike a .img file). Then open up an .img file for radio b and import the .csv file to replace the freq/repeater data and then upload it to radio b.
You import the .img file from the source radio into the tab of the destination radio (regardless of the vendor/model). The non-radio specific data is imported. Radio specific settings are ignored. No .csv file is required.
So if you are working with a group that has various makes & models of radios, a .CSV file is how you exchange the freq/repeater data.
Again, this can also be done just as easily with an .img file. The only time I ever mess with .csv files is to help those that do use them and have somehow corrupted theirs using a spreadsheet program, text editor, or some other program.
Lyle W9LRG
Jim KC9HI
Have you opened an issue on CHIRP website? That is the proper way to bring something to the attention of the CHIRP team.
I find your descriptions hard to follow, more a case of information overload than a lack of information.
If I understand your issue correctly, it seems you are reporting issues with CSV export/import, a facility the CHIRP team discourages using (as noted in 1a).
Here's what I would suggest to isolate the source of your problems:
1) Open CHIRP, load a valid img file, the EXPORT the contents to a CSV file.
2) Shut down CHIRP.
3) Open CHIRP, choose to make a new file, then IMPORT the previously saved CSV file.
That should work as expected, no issues.
Then I'd repeat the above, adding the following between step 2) and 3):
2.5) Open the CSV file previously created, change NOTHING, then save the CSV file.
(This will identify if Excel is modifying the CSV file format or contents.)
It should work as expected, no issues.
Then, as another test, repeat the above again, this time adding the following between step 2) and 3):
2.5) Open the CSV file and add one proper channel (inside 2m band), then save the CSV file.
(This will identify if your entry in Excel is causing the issue.)
It should work as expected, no issues.
And, finally, repeat the above again, this time adding the following between step 2) and 3):
2.5) Open the CSV file and add one RX only channel outside the 2m band, say a NWS WX channel, then save the CSV file.
(This will identify if the software is blocking an out-of-band channel. The Icom "guarantee" about frequency range is in regards to receiver performance specifications out-of-band.)
It should work as expected, no issues.
This process, tedious as it may seem, is, in my opinion, the best way to isolate the source of your issue - prove the Export/Import function works, then confirm Excel isn't reformatting/modifying the CSV file, then confirm your adding rows properly, then confirm out-of-band channels are accepted correctly by the radio.
Good luck - I have 2x IC-2100H radios and am interested in seeing this process work properly.
Ken, N2VIP
On Jan 11, 2024, at 08:45, Rich NE1EE TheDustyKey@imaginarian.org wrote:
GM, all, Thanks for this bit of testing. I intend to do my best to keep track of this topic, because I need to be clear in my docs to the ARES group.
As an erstwhile software engineer and programmer, I expect that the record reading routine instantiates a record structure populated with defaults, then proceeds to read the csv, filling in any valid data found. That would seem to create only valid complete records.
I've been using chirp-next, so that accounts for some of my success. I see that I am not using URCALL,RPT1CALL,RPT2CALL,DVCODE but I have ,,,, at the end of each line. I am using MS Office 2010, which I have been using for years, though I see that there have been updates to it that I have accepted.
- In the spreadsheet, I CLEAR all unused cells...I don't just leave them "apparently" empty. I Save As csv file. (all these files are available upon request)
1a. I open an img file from the 2100H, then IMPORT the csv (it IS an option, even if the popup says it isn't recommended), it appears that the img is updated SOMEWHAT correctly. Some memory lines are left blank, and I dont't see why...the csv lines look fine to me. If chirp sees too many commas in a row, does it get tired of processing nothing, and skip the rest of the line? Because I have this
4,EROCK4,147.465000,,,,,,23,NN,23,Tone->Tone,FM,5.00,,50W,EAST ROCK VOICE ONLY,,,,
and it is skipped.
If I choose to OPEN the csv file, the result is the same...I have blank lines in the csv file tab in chirp.
I then filled (spreadsheet) Offset, rToneFreq, cToneFreq with valid data, even though those fields are not used. For example, if a channel is simplex, there is no offset. If no tone option is specified, no tone value is needed. Hence CLEARing the fields in the spreadsheet, rather than leaving them "blank". If I don't CLEAR them, I get spaces twixt commas. I don't know how chirp handles those.
4,EROCK4,147.465000,,0.600000,,88.5,88.5,23,NN,23,Tone->Tone,FM,5.00,,50W,EAST ROCK VOICE ONLY,,,,
3a. I then opened the csv in chirp. The import stopped at line 23, but I suspect that is because the rest of the channels don't match the 2100H freq range (154.9..162.475). I'll check the specs. BUT now all the formerly blank lines are filled.
3b. I copied lines 1..23 from the csv tab to lines 1..23 in the ing tab, and it seems that all lines are correct. *** Unsed fields (see #3 above) are showing blank, as expected. I havna had a chance to load it into a 2100H and then read it, to see how that looks. BUT it seems that chirp is making some decisions I don't understand. I havna run into this before, because I tend to fill all fields, whether used or not, with defaults.
- I checked the 2100H specs. The RX is listed as
136–174 MHz, BUT *Guaranteed 144–148 MHz only.
Nonetheless, the deleted lines contain what seems to me to be valid data.
73 Rich NE1EE The Dusty Key On the banks of the Piscataqua
chirp_users mailing list chirp_users@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_users This message was sent to Ken Hansen at ken@n2vip.org To unsubscribe, send an email to chirp_users-unsubscribe@intrepid.danplanet.com To report this email as off-topic, please email chirp_users-owner@intrepid.danplanet.com Searchable archive: https://www.mail-archive.com/chirp_users@intrepid.danplanet.com
On 2024-01-11 10:55:, Ken Hansen wrote:
Have you opened an issue on CHIRP website? That is the proper way to bring something to the attention of the CHIRP team.
I thought it best to open a discussion here and get feedback: either someone points out my mistakes, or recommends I open a problem report. I didn't want to have folks spend time on a problem report if it is operator error. ~R~
On 2024-01-11 10:55:, Ken Hansen wrote:
I find your descriptions hard to follow, more a case of information overload than a lack of information.
I am used to describing things completely, which is why I wrote in separate paragraphs. However, I see that the replies are coming back to me a one GIANT paragraph, with no paragraphs, so maybe that is what everyone else sees, too. I can understand how confusing that must be. I don't know why this forum does that. I am on other mail lists that leave my emails with the paragraphs I sent.
~R~
On 2024-01-11 10:55:, Ken Hansen wrote:
If I understand your issue correctly, it seems you are reporting issues with CSV export/import, a facility the CHIRP team discourages using (as noted in 1a).
If it is discouraged, then remove it from the product. If it remains, then either tell me what I am doing wrong, or fix it. Please. You will note from my original email that both chirp methods of importing the csv file had the same results.
~R~
I'm not a CHIRP developer, I merely pointed out that they appear to discourage using CSV files, implying that fixing that facility may be a low priority issue for the team...
Ken, N2VIP
On Jan 11, 2024, at 10:26 AM, Rich NE1EE TheDustyKey@imaginarian.org wrote:
On 2024-01-11 10:55:, Ken Hansen wrote:
If I understand your issue correctly, it seems you are reporting issues with CSV export/import, a facility the CHIRP team discourages using (as noted in 1a).
If it is discouraged, then remove it from the product. If it remains, then either tell me what I am doing wrong, or fix it. Please. You will note from my original email that both chirp methods of importing the csv file had the same results.
~R~
chirp_users mailing list chirp_users@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_users This message was sent to Ken Hansen at ken@n2vip.org To unsubscribe, send an email to chirp_users-unsubscribe@intrepid.danplanet.com To report this email as off-topic, please email chirp_users-owner@intrepid.danplanet.com Searchable archive: https://www.mail-archive.com/chirp_users@intrepid.danplanet.com
I'm not a CHIRP developer, I merely pointed out that they appear to discourage using CSV files, implying that fixing that facility may be a low priority issue for the team...
No, we do not discourage them, and fixing CSV issues is a priority (for me at least) for sure. Jim and others' points are correct that CSV is not *necessary* just to transfer data between different models. CSV may be an unnecessary step if that's all you're using it for.
The CSV driver in CHIRP is different from others in that it can basically record any frequency on any band with any set of other attributes (like mode, tone modes, etc) which no real driver would ever allow. It's for that reason that I maintain my master frequency plan in a CSV file because the entire thing isn't accepted by any single radio I own. CSV is perfect for that.
The thing about CSV is that it is an _encoding_ and not a format. CHIRP has it's own method of using CSV to encode the data structures it needs to represent, and that of course, doesn't match with any other program. Excel (or other spreadsheet) can edit CSV files in a generic way and thus can be used in place of the CHIRP memory editor in principle. However, the user, or Excel (or both) can easily mess up the structure of the data while preserving the low-level CSV encoding (or could mess up the encoding as well) and make a file no longer readable in CHIRP. Within reason, those sorts of issues may be within the realm of something we want to fix, but of course, we can't and won't be able to read the mind of the person or tool that mangled one of our CSV files into doing the right thing.
Rich, you're wrong in your description of how we read a record and construct a memory from it (with respect to "defaults") for reasons I won't go into in depth here. You may (or may not) be right that we're choking on something that should be able to handle and thus could make a change. However, as you can see from the philosophical discussion here - this is probably not the best place to ask the question generically. If you think you've messed up your CSV file and want help with fixing it, then this might be the right forum (although without a sample of what you've got that doesn't work, nobody can provide anything useful). If you think what you've got should be accepted, then please open a bug, attach your log and the file you're trying to import, and let those of us that can do something about it have a look.
--Dan
On 2024-01-11 13:33:, Dan Smith via chirp_users wrote:
I'm not a CHIRP developer, I merely pointed out that they appear to discourage using CSV files, implying that fixing that facility may be a low priority issue for the team...
No, we do not discourage them, and fixing CSV issues is a priority (for me at least) for sure. Jim and others' points are correct that CSV is not *necessary* just to transfer data between different models. CSV may be an unnecessary step if that's all you're using it for.
Your email came through looking like a discussion, and not a solid stream of consciousness. You seem to be using an Apple product. Not sure what the authors of the trashed versions are. gmail? not clear to me. But this says that I /can/ get properly formatted, PLAIN TEXT messages from this list, so I won't bother looking for a way to change my email. Clearly proper newline codes are missing from some messages.
~R~
On 2024-01-11 13:33:, Dan Smith via chirp_users wrote:
If you think you've messed up your CSV file and want help with fixing it,
No...I am sure I understand the requirements, and thought I had explained that clearly. Apparently not. But my csv files are "correct".
If you think what you've got should be accepted, then please open a bug, attach your log and the file you're trying to import, and let those of us that can do something about it have a look.
Will do. Thanks Dan. I will organize my thoughts and files (assuming I can upload samples to the bug list), and submit one or more bug reports. I am trying to get my hands on a 2100H to test with, without bothering the folks at an EOC.
73 Rich NE1EE
On 2024-01-11 13:20:, Ken Hansen wrote:
I'm not a CHIRP developer, I merely pointed out that they appear to discourage using CSV files, implying that fixing that facility may be a low priority issue for the team... Ken, N2VIP
Thanks for the note. I have a workaround, as I documented in an earlier email, so I am fine. I simply need to fill "empty" fields with default data. I won't need to do this often, so as long as I can document what is needed, I am fine.
73 Rich NE1EE
In a previous life I was a software tester, that's why I suggested what did before - to try and identify the source of the issue, but that's doesn't seem to have been taken up, let's take another stab at this, see below:
On Jan 11, 2024, at 8:45 AM, Rich NE1EE TheDustyKey@imaginarian.org wrote:
GM, all, Thanks for this bit of testing. I intend to do my best to keep track of this topic, because I need to be clear in my docs to the ARES group.
OK
As an erstwhile software engineer and programmer, I expect that the record reading routine instantiates a record structure populated with defaults, then proceeds to read the csv, filling in any valid data found. That would seem to create only valid complete records.
Assuming how the software works may or may not be accurate.
I've been using chirp-next, so that accounts for some of my success. I see that I am not using URCALL,RPT1CALL,RPT2CALL,DVCODE but I have ,,,, at the end of each line. I am using MS Office 2010, which I have been using for years, though I see that there have been updates to it that I have accepted.
Your 14 year-old Excel is noted, and it makes sense your FM radio doesn't use DStar-specific fields.
- In the spreadsheet, I CLEAR all unused cells...I don't just leave them "apparently" empty. I Save As csv file. (all these files are available upon request)
So you've modified the exported CSV file...
1a. I open an img file from the 2100H, then IMPORT the csv (it IS an option, even if the popup says it isn't recommended), it appears that the img is updated SOMEWHAT correctly. Some memory lines are left blank, and I dont't see why...the csv lines look fine to me. If chirp sees too many commas in a row, does it get tired of processing nothing, and skip the rest of the line? Because I have this
4,EROCK4,147.465000,,,,,,23,NN,23,Tone->Tone,FM,5.00,,50W,EAST ROCK VOICE ONLY,,,,
and it is skipped.
Dunno, tell me more about the changes you made to the CSV file
- If I choose to OPEN the csv file, the result is the same...I have blank lines in the csv file tab in chirp.
Sounds like some lines are invalid...
- I then filled (spreadsheet) Offset, rToneFreq, cToneFreq with valid data, even though those fields are not used. For example, if a channel is simplex, there is no offset. If no tone option is specified, no tone value is needed. Hence CLEARing the fields in the spreadsheet, rather than leaving them "blank". If I don't CLEAR them, I get spaces twixt commas. I don't know how chirp handles those.
4,EROCK4,147.465000,,0.600000,,88.5,88.5,23,NN,23,Tone->Tone,FM,5.00,,50W,EAST ROCK VOICE ONLY,,,,
Not sure this CLEARing of unused fields is correct, many OEM programming applications keep default values in unused fields, maybe CHIRP doesn't like CLEARed fields instead of "blank" (however that is differentiated from "clear"?)
3a. I then opened the csv in chirp. The import stopped at line 23, but I suspect that is because the rest of the channels don't match the 2100H freq range (154.9..162.475). I'll check the specs. BUT now all the formerly blank lines are filled.
It's possible CHIRP is blocking out-of-band frequencies, if so, it should be easy to prove - program an out-of-band frequency into radio front panel, then read off of radio, confirm freq in img file in chirp, then export, and import CSV, confirming the file contains the output-of-band freq/channel.
If this fails to import, CHIRP is blocking the upload, if it all works, the issue has to do with the fields you manually entered/rows you created.
3b. I copied lines 1..23 from the csv tab to lines 1..23 in the ing tab, and it seems that all lines are correct. *** Unsed fields (see #3 above) are showing blank, as expected. I havna had a chance to load it into a 2100H and then read it, to see how that looks. BUT it seems that chirp is making some decisions I don't understand. I havna run into this before, because I tend to fill all fields, whether used or not, with defaults.
I suspect the answer lies in the handling of "blank", "clear", and "default values"...
- I checked the 2100H specs. The RX is listed as
136–174 MHz, BUT *Guaranteed 144–148 MHz only.
The radio will accept/receive out-of-band (136-144, 148-174 MHz), but the specs aren't guaranteed.
Nonetheless, the deleted lines contain what seems to me to be valid data.
OK
73 Rich NE1EE The Dusty Key On the banks of the Piscataqua
chirp_users mailing list chirp_users@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_users This message was sent to Ken Hansen at ken@n2vip.org To unsubscribe, send an email to chirp_users-unsubscribe@intrepid.danplanet.com To report this email as off-topic, please email chirp_users-owner@intrepid.danplanet.com Searchable archive: https://www.mail-archive.com/chirp_users@intrepid.danplanet.com
participants (6)
-
Dan Smith -
Jim Unroe -
Ken Hansen -
Lyle Giese -
Nigel A. Gunn G8IFF/W8IFF -
Rich NE1EE