When importing a CSV file into an IC-2820 with CHIRP all looks fine, however if you then open it up with the CS-2820 program some, not all, of the DSQL fields display "error" and the CODE field displays "127" instead of "00". This is occuring on some DV memory channels, but fairly consistently. I cleaned up a ICF file, then went through the process a couple of times importing a CSV file through CHIRP and it happened on each occasion.
Okay, I was able to reproduce this issue and I have a fix for it. It's not actually something CHIRP was doing, but rather something it wasn't doing that was the problem. Apparently when you switch to DV mode on the radio or CS-2820, there is a bit of logic to clear/reset/initialize two of the bytes in the memory location that pertain to the DSQL/CSQL/code values. CHIRP wasn't doing that, and thus whatever garbage was there before remained, and CS-2820 didn't like it.
So, I've got a fix to clear those values *if* we're setting a non-DV memory to DV mode. The reason I'm doing this instead of blindly resetting them is so that if you've set the values in your radio (since CHIRP doesn't support them), I don't want to clobber them. Thus, to see this fix, you'll need to do something like reset your radio and re-import from CSV or some such (let me know if that doesn't make any sense).
Anyway, give 0.1.9b4 a shot and let me know if it fixes the issue for you.
On a secondary issue, I discovered yesterday when importing a CSV file into the IC-92AD, with CHIRP 0.1.8, that if a frequency is out of range (example: 136.6375, instead of 146.6375) then CHIRP locked up and had to be killed / restarted.
I have not been able to replicate this with 0.1.9b3. Can you? If you can, perhaps you can send me the CSV file you're importing, and perhaps an ICF of your radio that I can import into mine before I try the import.
Also, if you have a debug log of this particular scenario, it might have something useful in it.
Thanks!