CHIRP

I'm not sure how you expect us to actually reproduce this or tell you what is wrong without the CSV file, but let me say: please attach a CSV file you're trying to import.

The message you're showing is clearly telling you what the problem is: your dtcs or rx_dtcs columns have invalid things in them. But if you will attach a file you're trying to import I can explain more about why specifically.

Yeah, so the header row has been changed for one thing. You can't do that because then CHIRP can't tell which column is which in all the remaining records. That means things in those columns will basically be ignored by CHIRP, which means the tone mode and the two tone columns, which I suspect is your main issue.

However, as the message is indicating, line 68 is invalid. Indeed you're telling chirp that memory #67 should have no frequency, no mode, etc, etc:

67,,,,,,,,,,,,,,,,

That's a totally invalid record as far as CHIRP is concerned. If I delete those (and all the bunch at the end of the file) I can open it without any reported errors. But, you've got other things that are obviously invalid, like these memories with names but no frequency:

7,XB U1,,,0,TSQL,,,23,NN,FM,25,S,,,,

The headers in this CSV are directly from chirp; I pulled up the image for this radio from another city, exported it as a .csv form chirp, deleted the old city information, then copy/pasted the new information into the correct column from my master frequency workbook for the new city.

Memory channels 7-12 have data I removed for privacy; those can be ignored as I'll put that data back in the version I attempt to import again.
Memory channels 67, 68, and 69 are empty, per my progamnming scheme. I start my repeaters @ channel 70 on all of my radios to keep my mind sane.

If you look at the screenshots, there's a side by side comparison of what is in the .csv, and what Chierpo actually imported; there's a LOT of blanks in Chirp.

The headers in this CSV are directly from chirp; I pulled up the image for this radio from another city, exported it as a .csv form chirp, deleted the old city information, then copy/pasted the new information into the correct column from my master frequency workbook for the new city.

They're really not:

$ head -n1 ~/Downloads/test.csv
Location,Name,Frequency,Duplex,Offset,Tone,rToneFreq,cToneFreq,DtcsCode,DtcsPolarity,RxDtcsCode,CrossMode,Mode,TStep,Skip,Power,Comment,URCALL,RPT1CALL,RPT2CALL,DVCODE
$ head -n1 ~/Downloads/COS\ 10APR24.csv
Location,Name,Frequency,Duplex,Offset,Tone Mode,Tone Squelch (RX),Tone (TX),DtcsCode,DtcsPolarity,Mode,TStep,Skip,Comment,URCALL,RPT1CALL,RPT2CALL

It looks to me like you're typing the names of the columns in CHIRP's UI into your spreadsheet, but that's not the same as what belongs in the CSV format. You need to export a CSV file and keep that header intact and exact.

Memory channels 67, 68, and 69 are empty, per my progamnming scheme. I start my repeaters @ channel 70 on all of my radios to keep my mind sane.

If you look at the screenshots, there's a side by side comparison of what is in the .csv, and what Chierpo actually imported; there's a LOT of blanks in Chirp.

Yeah, blanks (i.e. gaps) in the file are fine. Lines that claim to have numbered memories with blank data in them are not. Export the CSV file from CHIRP with blanks and you'll see.

CHIRP is not a spreadsheet and a spreadsheet is not a memory editor. CSV is a record-encoding scheme, it's not really a file format. If you want to maintain your memories in a spreadsheet, you're going to have to stick to some rules and/or clean up things your spreadsheet does that make no sense to CHIRP.

Does anyone else have anything to say?
Arguing with Dan Smith isn't fun, or helpful, and this guy seems hell-bent on assuming.

Daniel Leach wrote in #note-6:

Does anyone else have anything to say?
Arguing with Dan Smith isn't fun, or helpful, and this guy seems hell-bent on assuming.

Sure. I agree with Dan. You can't just throw any CSV file at CHIRP. It must be in a valid CHIRP format or it won't work.

The best way for creating valid records is to program then in the memory editor and then export them to a CSV. If you insist on doing it the other way, then you must match the format that CHIRP requires/understands.

I'm seeking helpful responses from people who have read the details I've provided, and, preferably, are not making assumptions, or otherwise altering the facts.
Currently, the issue persists and I'm not able to program my Anytone 5888UVIII because of this issue.
Also, I just updated to the latest version of Chirp again this morning.

Sorry, but but I only see a single CSV file submitted to this issue. Dan looked it over and pointed out a few things that make it incompatible with CHIRP.

I just took a look at it. Dan is correct. It is not in a format that can be used by CHIRP. There is nothing that can be done until you supply a properly formatted an valid CHIRP CSV file. Once you have one and you still have issues, then something can be done to resolve them.

Well, if what you're saying is true, then Chirp is at fault.

Running it down AGAIN:

The steps I took:
I opened Chirp.
I updated Chirp per the prompt.
I opened Chirp again.
I opened a radio file for this radio.

• This radio file had been used to program this radio successfully with no issues about 18 months ago. I deleted some of the memory channels from the radio file that I do not want to use for the current programming. I saved the modified radio file as the (Radio) (State) (City) format that I like to use (different from the file name that I opened, it's for a different city).

ISSUE # 1:
When I attempted to copy/paste information from my Master Frequency Plan .xlsx spreadsheet, Chirp would not allow me to paste ANY data into it.

• I could not paste a column of data.
• I could not paste a row of data.
• I could not paste a single cell of data.
• I COULD paste the data from my Excel spreadsheet into anything else I wanted to; notepad, google sheets, LibreOffice Calc, and my web browsers.

Since I could not get the data INTO Chirp using the copy/paste method, I opted for 'plan B', the .csv.

Again in Chirp, in the new file for the new city I want to program my radio to,
I exported the file as a .csv.
I opened the .csv with LibreOffice.
I put the .csv from Chirp on the left side of my big monitor.
I put the .xlsx 'master frequency plan' on the right side of my big monitor.
I compared the column names to make sure I understood which data went where.

*** SIDE NOTES, PLEASE BE SURE TO READ THREE TIMES TO FULL UNDERSTAND (Have I ever told you how annoying it is to deal with people who ignore details, make assumptions, and blame the user???)

*** My Master Frequency Plan Workbook was started by exporting a program I made (called my 'Standard Frequency plan) from Chirp as a .csv, saving it as a .xlsx, then making the column headers BOLD and freezing the top row. I did this to help me manage the data in the sheet in the same way Chirp wants it to make programming new cities faster/easier.
*** When I put new data into my master frequency plan workbook, I make a copy (duplicate) of the 'Standard' tab, rename the new tab as whatever city it's for, then add the data (Frequency, tone, offset, duplex, etc) into the correct columns per the column label I received from Chirp.
*** When I copy data from the Master Frequency Plan to a Chirp .csv (Or any other software's .csv), I copy/paste the data in sections based on the layout I received from the program.

• Some of the columns were not in the same order, so I copy/pasted all of the data in the columns that WERE in order into the .csv from Chirp, then repeated that. Where I had a column from the Chirp .csv that I did not have data for in my MFP, I simply looked at what data Chirp had in there already, and copied that data, modifying it if needed for that particular channel based on what Chirp has in the column of the .csv.

I insert the data from my MFP into the Chirp .csv, making sure to match the stuff Chirp is looking for.
I saved the .csv, and closed the file.
I return to Chirp, select File> Import, select the .csv I was just working with (I only work with one at a time, and I save that file on my desktop, it's the ONLY .csv on the desktop, to make sure I only have the one).

Issue # 2:
When I import the .csv, I get some errors (shown in the screenshots).
Sometimes it won't allow me to move forward, and Chirp shuts down.
Other times, it let me move forward anyway, but it only imported SOME Of the date from the .csv (As shown in the screenshots where I have Chirp and the .csv I imported FROM side by side on the big screen).

Some background information:
First, I have sucesfully programmed all of these radios:
Anytone AT-5888UV-III
Yaesu VX-8R
Baofeng UV-5R (3 different submodels/file sets)
Baofeng UV-82
Baofeng UV-82 HP
Retevis RT-22
Retevis RT-68
(and some more)
Using the copy/paste method from my MFP into Chirp in at least 5 cities,
and,
using the .csv method many more times before I learned I could paste directly into Chirp (which I can not do now).

Second,
I was able to program my Kenwood V-71a using the .csv method and my MFP without any issues.
I opened the current city radio file in MCP-2a, exported it as a .hmk (It doesn't have a .csv option)
Opened the .hmk with LibreOffice Calc as a .csv,
Deleted the channel information I did NOT want,
Pasted the channel information I DID want from my new city plan in my MFP,
Saved the file as a .hmk,
imported it into MCp-2a,
verified the settings for the radio were correct,
saved the file as an MCP-2a format file for th enew city name,
and wrote it to the radio.

Lastly, some of the things you've save that are wrong:
1) You've said I'm trying to program my radio with a .csv; I am not.
I am attempting to program my Anytone AT-5888UV-III using Chirp.
2) You've said my file is not propely formatted for Chirp.
Since the .csv file I'm using is directly exported from Chirp, and since I did not change the layout or formatting, then that issue is caused by Chirp.

I'm looking forward to seeing responses with actionable assistance for the two issues I've detailed in this thread.

Again, I'm seeking HELP.
All I see is you blaming me for the issues and continuing to insult me.
I'm sorry you think that's appropriate, but it's not.

Daniel,

You are the one who is being insulting. You're using a free product and leaning on advice given out of other's free time and good will. I'd recommend that you back off your defensive position and assuming insult where there is none.

In any case, for anyone else who may be searching for this problem. A common problem especially with Excel is the default CSV format is UTF-8 which causes issues with Chirp for some reason. Just looking at the files in a text editor they will appear similar but Chirp will reject it. When saving the CSV ensure you are selected the generic CSV option that is further down in the dropdown. I'm not sure what LibreOffice defaults to but maybe try some of the other CSV options if it has it.

In any case, for anyone else who may be searching for this problem. A common problem especially with Excel is the default CSV format is UTF-8 which causes issues with Chirp for some reason. Just looking at the files in a text editor they will appear similar but Chirp will reject it. When saving the CSV ensure you are selected the generic CSV option that is further down in the dropdown. I'm not sure what LibreOffice defaults to but maybe try some of the other CSV options if it has it.

That's a good thought, but I don't think that's his problem. We can fix (and have fixed) his file by changing the header and memory lines to the proper format, but also because his file is straight ASCII:

$ grep --color='auto' -P -n "[\x80-\xFF]" COS\ 10APR24.csv
$

As of not too long after the upgrade to python3, we should be fully tolerant of UTF-8 CSV files, and we've got automated tests that make sure we don't regress that functionality. We also support BOM signatures on those files. If you still have issues with UTF-8, please file a separate bug with some samples and I'll gladly fix it.

You're definitely right though that we struggled with that a lot in the legacy python2 CHIRP code.

Asking for help here, or, refusing to tolerate being blamed for things I did not do is considering 'insulting' here, got it.
Won't ask for help here again, and then I won't have to refuse to tolerate being blamed for things I did not do.

Consider this issue closed, unresolved, and I'll have to find some other software or way to program my radios since Chirp is not working now.

Ah it may be because I'm using MacOS? I'll see if I can gen up a buggy file for it though!