Hi. I use a Kuhne transvertor port on my IC7300 to use me 2m transvertor. The rig uses 28MHz so on the rig it displays 28.1774 and the actual freq I am listening to via the transvertor is 144.174 - a 115.9966 offset.
Is it possible to have a correction feature inm this software for this?
It is a great product, very impressed with its features
It’s a neat idea. It might be a bit complicated due to the number of places within the program that the current frequency (and desired frequency) is used. But if we think of a way to slip it in there, I suppose we will.
I developed a partial solution for transverter support for the Icoms using CI-V bus. It is a band decoder, a PTT breakout, and/or a remote control head. It uses USB or BT/BLE.
2 versions so far:
M5stack or M5AtomS3 or headless M5stampS3 with GPIO and/or relay modules for relay control (antennas, transverters, PTT breakout, amps, etc). BT or BLE only (So IC-705 only). Have not got USB Serial Host to work reliably. The display, if present, shows the transverter RF frequency, 8-digit grid square, band, time, XVTR active status and TX status. Accepts PTT input from polling the radio or hardware from GPIO. A neat feature is that is stores the last used NON-Xvtr band radio parameters as well as transverter band radio parameters. When a Xvtr band is selected (from hardwire input or button), the last used band is saved, the IF changed to the last stored values, then when switching away from a Xvtr band, the last used band is restored. The last used band maybe the same as the IF. For example, you may be on 144.200 in USB voice, then switch to 903Mhz and use an IF of 145.174 (for 903.174) MHz in USB-D with FT-8. Same radio side band, different set of parameters (mode, AGC, filter, frequency, preamp, atten, split). I am working on PC pass through for WSJT-X and logging so they see the Xvtr frequency and avoid CI-V bus conflicts. GitHUb repo at https://github.com/K7MDL2/IC-705-BLE-Serial-Example
Teensy 4 over USB only. Works with many USB CIV radios. Would be easy to use hardware serial. This has 3 serial ports active on the PC side (if attached), one for debug, one for GPS data pass through to a PC (if attached), one for CI-V CAT data. The USB Host side connects to the radio with 2 serial ports, GPS (ch B) and CAT (ch A). This version can be used headless or with a screen. In one config it is a simple band decoder with (for now) hard coded output patterns. In another configuration I run it on my Teensy SDR chassis with 4.3" or 7" touchscreen, encoders, and switches. It is configured as a master control head with preconfigured bands from AM radio to 122GHz. It stores the most used radio parameters per band, so all transverter bands are equals with normal bands. The touch screen shows the full length RF frequency, the radio of course will only show the IF frequency. I am working on improving the PC CI-V passthrough feature to deal with polling conflicts and translate the CI-V frequency messages so that PC side programs like WSJT-X and logging programs see the transverter frequency, not the radio frequency.
I have started looking at using the decoders in combo with wfView. I cannot pass the audio to the PC over CIV or BT with these controller CPUs, only serial data (or MIDI). So I use the LAN/WLAN connection for the audio. I could use the LAN CAT data with wfView but today it would be only the radio “IF”. So as a workaround I would use the USB CI-V data I pass through from my controller which has translated frequency.
A simpler solution would be to have at minimum the transverter offset in wfView and a customizable band menu screen. The decoder continues to be used but now only as a remote display (optional) and band decoder and PT breakout, it can do all the radio band saving and restore work as today.
A maximum solution is to “absorb” the above logic and configure each band with stored last used parameters. Even do band decoder and PTT breakout though USB relays. Otherwise, my band decoder is plugged into BT or USB and focuses on display and IO. Git Hub repo at https://github.com/K7MDL2/ICOM_IC-905_CIV
An interesting twist is to establish a connection between wfView and my controller via some protocol, MIDI even, such that I do not even connect to the radio directly. It becomes a USB device (vs host) controlled by wfView. The controller would also provide physical controls to act like a control pod. Memory selection, band select, more knobs. wfView could be running on a headless CPU buried unde rthe back seat of my rover truck.
FYI, I use the band stacking register command to populate over my database defaults. Then as each band is operated, the radio updates the database values.
While some loggers such as N1MM+ offer radio + transverter support, other like N3FJP do not.
In my use cases so far, I always have wfView audio connected to virtual audio cables for WSJT-X. The radio audio still works independently in parallel (as does CI-V) so not urgent need for switching audio based on data mode (USB-D vs USB).