I offer so much thanks for all who work on the CHIRP platform.

K7NQB 73

---------- Original Message ---------- From: Dan Smith via chirp_users chirp_users@intrepid.danplanet.com To: Discussion of CHIRP chirp_users@intrepid.danplanet.com Subject: Re: [chirp_users] Icom IC-2100H, Excel spreadsheet, csv files, chirp-next-20240111-win64 Date: Thu, 11 Jan 2024 10:33:11 -0800

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 _______________________________________________ chirp_users mailing list chirp_users@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_users This message was sent to Nick at papanick@netzero.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