Is there a way to get rigctld emulation working when running the wfserver (headless) build? I tried enabling by adding EnableRigCtlD=true under [LAN] in the config file, but it seems to do nothing. Looking at the code, I realized that rigctld isn’t included in wfserver.pro. Is there a way for me to include it in the build manually?
I tried simply adding the related lines in the include and src lists as they appear in wfview.pro, but the resulting binary didn’t seem to respond when I tried to connect via rigctl.
My goal is to automate the power state of the IC-7300 with a smart switch on the power supply, connected via Home Assistant (that part I can handle). I should note that I’m not a ham expert; I am helping to make my dad’s rig more versatile; he is the ham enthusiast in the family (@bwkeys1).
wfserver is designed to allow a remote instance of wfview (graphical client) to connect and use a radio that doesn’t otherwise have a network connection. wfserver handles the remote audio and control commands to the radio. As such, it doesn’t have most of the features of the graphical wfview client.
How does this tie into your “automate the power state” goal? wfview client can of course send the power on command to remotely turn on the IC-7300.
When the smart plug into which the radio’s power supply is connected is switched off remotely through Home Assistant, an automation will first run rigctl -m 2 -r 127.0.0.1:4533 set_powerstat 0 on the Pi running wfserver (via SSH). The automation will wait a few seconds and then actually send the command to turn off the smart plug. The goal is to protect the rig in the event that the smart plug is told to turn off while the radio is active (or even transmitting).
wfserver is running well on the Pi, dutifully providing access to my dad’s wfview client on his laptop. I did test rigctld on the client in this case, and it worked well; but I’m trying to make this automation work whether a wfview client is connected or not. That is why I’m trying to get rigctld emulation working in wfserver.
I think you would be fine to just “yank the plug” whenever you want. On my remote system, that’s what I am doing. I’m using solid state relays on the 12V side. These embedded systems are designed to handle power downs that aren’t always graceful.
If you wanted to do this, you will need to kill the wfview server and then run the rigctl command directly to the USB serial port. It’ll definitely complicate things. Alternately, place the responsibility on the client side and have your dad hit the Power Off button in wfview client when he is done using it each time.
I think you would be fine to just “yank the plug” whenever you want.
OK. I wasn’t sure that was the case. I’ve corrupted an SD card before by pulling the power on a Pi, and these days I try to let everything shut down gracefully where I can.
If you wanted to do this, you will need to kill the wfview server and then run the rigctl command directly to the USB serial port.
I thought of that but didn’t want to go that deep down the rabbit hole.
Alternately, place the responsibility on the client side and have your dad hit the Power Off button in wfview client when he is done using it each time.
Yes, he usually does this already.
Thanks for your reply. With that, I think I’ll call it good and leave the system as is. Thanks for creating such a versatile piece of software!
Hello.
Sorry, but regarding the topic at hand, here’s some information that’s been on my mind lately.
ICOM has stated that if you don’t control the power supply from the radio itself, the “protective operation of the receive circuit may not complete properly” on the IC-7300 and 7300MK2.
Andrew idea is a good one.
think that the 7300 has back-to-back limiter diodes to protect the RX input.
All relays except for the ATU will be non-latching so I cannot come up with why, except for:
If the SD card is being written to, not cleanly umounted, it may end up corrupted and that generally can be reformatted.
Isn’t this a facebook regurgitating tale?
If ICOM states this, I assume there will be a verifiable link… quick documentation checks did not come up with anything like it yet for me.
If the SD card is being written to, not cleanly umounted, it may end up corrupted and that generally can be reformatted.
I think we are conflating two different subjects. I have not had any SD card problems with my wfserver Pi… I had this unfortunate experience on an unrelated project. I mentioned it here to illustrate how I learned that computer systems in general often need a graceful shutdown before power is removed. I know that embedded systems are usually more tolerant of having the power suddenly disconnected, but I make no assumptions here…
What kind of protection is built into the IC-7300 I do not know. That’s not my field of expertise. I’m a software guy that deals with hardware when I have to. I’m not even a ham operator—just here to support my dad’s hobby.
If it turns out that switching the power off is completely safe for the IC-7300, great. I don’t have to do anything else. If it turns out that cutting power can cause an issue, I’ll continue down the rabbit hole to make sure the radio is powered off via set_powerstat 0 before power is actually cut.
IC - 7300 ni wa, jushin kairo hogo no tame dengen OFF-ji ni antena to jushin kairo o kirihanasu kinō o sōbi shite orimasu. TR TUM kono kinō wa, IC - 7300-gawa kara dengen o kitta sai ni dōsa suru shiyō to natte ori, anteikadengen-gawa kara dengen o kira reta koto ga gen’in de kono kinō ga hatarakanakatta to suisoku sa reru koshō jirei ga hassei shite orimasu. 31000. 00 Kanarazu IC - 7300-gawa kara dengen o o kiri kudasai. Aikomu kabushikigaisha ripeasentā 094. 00
The English translation appears to be this (using Apple Translate):
The IC-7300 is equipped with a function that separates the antenna and the receiving circuit when the power is turned off to protect the receiving circuit.
This function is designed to work when the power is turned off from the IC-7300 side, and there are cases of failures that speculate that this function did not work because the power was turned off from the stabilized power side.
Please be sure to turn off the power from the IC-7300 side.
Icom Co., Ltd. Repair Center
If I’m understanding correctly, does this mean that it is best to always turn off the IC-7300 using the power button on the front of the unit (or by using wfview’s Power Off function) before turning off the power supply?
That’s right.
I received a response from ICOM after sending the radio in for repair; the issue occurred when I repeatedly turned the radio on and off using a stabilized power supply.
I appreciate that you shared this correspondence with us. It is doubtlessly valuable information for this group.
I hope we can find the “root cause” within the schematic of the radio and gain better understanding of what happened.
My questions:
How protected is the radio when it is powered on?
When the power button off procedure is followed, and then the radio DC power is removed, what component(s) are held in a special state?
Can similar functionality be achieved with external protection devices on the coax (a coax switch, for example, ought to do the trick if switched to the off position).
Which other radios may have similar procedures required?
Does the engagement of the ATU (antenna tuner) have any bearing on these findings?
I hope to find some time to go over the 7300 receiver schematic and answer some of these questions. And I look forward to any information anyone here can offer on the topic.
Hello,
I have submitted a query to Icom regarding points 1 through 5 above.
------- Response
We would like to respond to your inquiry.
When returning a repaired unit, we do include a notice sheet as you mentioned.
However, we do not disclose detailed information regarding the circuitry or operation.
We apologize for any inconvenience and ask for your understanding.
We apologize for not being able to meet your expectations.
This concludes our response.
It seems the only way to investigate this is to trace the circuit diagram.
If the only problem is lack of protection of the receiver from something nasty coming down the antenna then Elliott’s suggestion of a co-ax switch to disconnect the antenna seems good. Maybe in a remote installation a co-ax relay powered from the radio 12V supply that only connects the antenna when the radio is powered on is a good idea? A changeover relay could actually ground the antenna when not in use.
This little python program will send the “power on” sequence to the radio. You need to make sure wfserver is not running at the same time.
For example: civpoweron.py /dev/ttyUSB2 98h 19200
Would power on my IC-7610 via the “remote” jack at 19200 baud. You only need to get the radio’s default ci-v address correct (and maybe it’ll work with 0x00 a la CI-V Transceive, not sure). There is a parameter in the code, " PREAMBLE_COUNT", which determines how many times 0xFE is sent to “wake up” the radio. It may be that some radios require more FE than others.
If you can test with the IC-7100 and others, maybe we can find a good PREAMBLE_COUNT and modify wfview to more successfully power on more radios? I have heard of issues “powering back on” from a few users with a variety of radios.
You can get very basic CI-V to USB adapters on ebay, often under $10. This could be a nice “backdoor” to get in to the radio when the USB command is failing to do the trick. At the very least, it gives you two serial port interfaces to the rig. For a remote rig, it would seem a good thing to try. My IC-7610 can be powered on and off via the 1/8" “REMOTE” jack just fine using that python script I posted.
