Ah-ha, I found the right forum for help...
I have a HobbyPCB RS-HFIQ that I use with Quisk running on a Raspberry Pi 4.? Works great for digimodes, including CW via Fldigi.? However, I would like to do CW via a key/paddles.? I'm trying to figure out the mechanization for that with Quisk.
Review quick_hardware_model.py, quisk_conf_defaults.py, quisk.c, and is_key_down.c, I figure out how to assert the key line in Quisk with Ethernet (I was going to add my own GPIO logic, but decided to start with something that's already there).? I configured the Ethernet key in .quisk_conf.py, and connected to it with netcat on port 21820 (I think it was).? Eventually I figured out how to send binary 0 and 1 to the port (in retrospect, I think I could have just used a character with the correct LSB).? Anyway, I see that this turns on and off they key (my waterfall stops/start when I send the bit through), but it does NOT assert PTT, so the rig does not transmit.? So I'm thinking my assumptions going into this effort need to be validated and/or re-worked.
Some questions:
(1) Does Quisk generate the appropriate I/Q data for a CW carrier at the currently selected frequency?? I think the answer is yes (and as I was typing this, I realized I can probably check this by hooking up headphones to the TX audio out from the soundcard...)
(2) What are the assumptions underlying Quisk's hardware key implementation?? Does Quisk assume the hardware key is already coupled to the RX/TX (PTT) on the rig?? (i.e. Is Quisk assuming that, when the H/W key is asserted, that is coming from the rig, and the rig is already handling transmit?? (In which case Quisk is just handling generation of I/Q.) Or am I missing some necessary 'glue' in my Quisk hardware configuration to cause PTT to be set with the key?
(3) What are other folks' implementations of this?? Is USB serial to the rig, for switching transmit, fast enough?? Or do I need to use my Pi's GPIO pins to interface to the external PTT line on the RS-HFIQ?
Thanks!
Rob KC4UPR
