Feature #185
closedConvert split channels to offset during import
Added by Chris Kantarjiev almost 12 years ago. Updated about 11 years ago.
100%
Description
In addition to 'normal' HAM repeaters, I do a lot of work in the public service VHF bands. The repeaters there have "odd" splits, and it is error-prone to have to do the math to program them into CHIRP (+4.285? +8.335? etc).
It would be very useful to have a Duplex mode, perhaps "SPLIT", that allows me to enter the input frequency directly into the Offset column; this is how the native PX-777 and Kenwood software works.
Files
| split_test.csv (211 Bytes) split_test.csv | Chris Kantarjiev, 02/05/2013 10:15 AM | ||
| split_test.csv (212 Bytes) split_test.csv | Chris Kantarjiev, 02/08/2013 05:31 PM |
Related issues
Updated by Tom Hayward almost 12 years ago
- Status changed from New to Feedback
This feature was added in r691, back in 2010. I use it all the time. Which radio are you trying to use it with?
Updated by Chris Kantarjiev almost 12 years ago
Trying to use it with the PX-777+. I only saw duplex modes of +, -, and None. Channels that are already programmed with odd splits show the direction (+ or -) and the offset of several MHz.
Updated by Tom Hayward almost 12 years ago
Ah, the issue here is that you're trying to program odd splits into a radio that doesn't support odd splits. It sounds like the Puxing software is emulating odd split support by calculating the offset for you. Chirp doesn't do this right now, but it may soon :-)
Updated by Chris Kantarjiev almost 12 years ago
Yes, the radio's VFO mode requires you to compute the split and set the split and offset. The software makes this invisible, which is very very useful!
Updated by Peter Gamache over 11 years ago
In addition, it would be nice to support split TX (including VHF/UHF splits) in the .CHIRP export format. Currently CSV works, but .CHIRP doesn't.
Updated by Chris Kantarjiev about 11 years ago
- File split_test.csv split_test.csv added
Any updates on this? I see that the CSV pane now supports "split" as a duplex type, which is exactly what I want, but when I try to paste a row (sample attached) into a PX-777 window, I get an error.
Updated by Tom Hayward about 11 years ago
- Chirp Version changed from 0.2.2 to 0.2.3
Here's the issue with the PX-777: it supports programming a TX frequency, but doesn't differentiate between offset and split. We could allow you to type/paste a split, but when you download from the radio next time it will read as an offset (properly calculated, of course).
I think the best option here will be to add functionality to the import/export/paste code so that when an odd-split is encountered in a csv and the destination doesn't support odd-split, Chirp automatically converts it to an offset, saving you from having to do the math or getting an error.
Updated by Chris Kantarjiev about 11 years ago
I'm now using the 2013-02-04 daily.
Updated by Chris Kantarjiev about 11 years ago
I would be very happy with what you propose.
My main interest in this is being able to distribute/maintain a single CSV or IMG that covers our band plan and can be used with CHIRP to program the various radios in our SAR unit: PX-777, D710, FT-60, D72, etc.
Thanks!
Updated by Tom Hayward about 11 years ago
- Subject changed from Support split channels with direct frequency input to Convert split channels to offset during import
- Assignee set to Tom Hayward
- Target version set to 0.3.0
I understand; I do exactly the same! Unfortunately my D72 balks at splinter channels like 155.3025 MHz and Chirp reports an error--a different problem, but still import related. Not really a big deal anyway, I generally monitor those channels with Part 90 receivers so that I can respond if needed.
Updated by Chris Kantarjiev about 11 years ago
It's probably worth noting that the PX-777 is Part 90 approved, which is one of the reasons we like it so much...
Updated by Tom Hayward about 11 years ago
Understood. I have all four of the radios you mentioned on the desk in front of me.
Updated by Tom Hayward about 11 years ago
- Status changed from Feedback to Resolved
- % Done changed from 0 to 100
Done. Will close after testing by reporter.
Updated by Chris Kantarjiev about 11 years ago
Look forward to testing ... in tonight's build?
Updated by Tom Hayward about 11 years ago
Chris Kantarjiev wrote:
Look forward to testing ... in tonight's build?
Yes, or the source code right now.
Updated by Chris Kantarjiev about 11 years ago
Hmm. Doesn't work for me in the 0.3.0 release.
I opened a .img file that is from a PX-777. I opened the split_test.csv. I tried to copy the row from the split_test.csv and paste it into the PX-777 window, and got the usual error about not supporting Duplex Split.
Maybe it's a problem with the .img file being old; I'll go find my radio and try reading from the memory.
Updated by Chris Kantarjiev about 11 years ago
Nope.
Hooked up the PX-777+, did an "upload from radio". Tried to paste the row from split_test.csv, and got the same error.
Updated by Tom Hayward about 11 years ago
There's a sanity check of 7 MHz maximum split for VHF highband. You're using an unrealistic split of 11 MHz which the import logic assumes is an error and ignores.
Updated by Chris Kantarjiev about 11 years ago
- File split_test.csv split_test.csv added
Doh! You found a typo for me! But ... that's a bogusHHHHHmisleading error message...
I attach a new file, with a 4.3 split. Doesn't work, either.
Updated by Tom Hayward about 11 years ago
- Status changed from Closed to In Progress
- Target version changed from 0.3.0 to 0.3.1
Ok, you got me there. None of the systems around here have splits that large so I programmed the max smaller. I just bumped the max split up to 15 MHz, so once that fix makes it into a daily build it should work for you.
Updated by Chris Kantarjiev about 11 years ago
OK, I'm a little confused, still.
Yes, the original split_test file had an 11MHz split, but it was a typo on my part. I don't need it to be that big. I would argue that the error message should complain about too big a split rather than that the duplex split isn't supported :-)
But on my last update to this ticket, I attached a new split_test.csv that has a 4.3MHz split, which also didn't work in the release build.
Just want to make sure that you're chasing the right problem ... thanks!
Updated by Tom Hayward about 11 years ago
The error message is because if it's not a nice small split, the import logic keeps its hands off the situation. If the automagic doesn't happen it tries to copy the split directly. This succeeds on any radio that supports odd split, but on yours reports "odd split not supported".
The split in your example file is 8.335 MHz.
Updated by Tom Hayward about 11 years ago
- Status changed from In Progress to Resolved
- Chirp Version changed from 0.2.3 to 0.3.0
Does the new 15 MHz max split in Chirp daily work for you?
Updated by Chris Kantarjiev about 11 years ago
Sorry that I don't seem to be able to do simple subtraction any more.
Yes, the 20130210 daily build allows me to paste that row into a px-777 image pane with the proper offset. That's wicked cool, thanks. I don't have my radio to hand at the moment, so I can't confirm that it programs correctly, but it certainly seems that it should work after that point.
Updated by Tom Hayward about 11 years ago
- Status changed from Resolved to Closed
Indeed, I didn't touch the programming code for any specific radio, so you don't have to worry about changes there.
I'm also considering allowing channels to be programmed as offset or split regardless of the radio support. So +, -, and split would show in the dropdown, and Chirp would be smart enough to know which ones needed math applied before storing. Stay tuned for that (in a different issue).