Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - pe1hzg

Pages: [1]
1
With the current energy prices, it is desirable to switch-off a remote site when not in use. The Webswitch 1216 would be desirable but is not available. And solid-state relays, like the RP1A48D5 are readily available at Reichelt and can be used to switch 230Vac.

The RRC1258 are open collector so the relays should be connected between the OUT ports (pin 5, 6, and 3 of the I/O connector) and the 8V out (pin 7 of the I/O connector). The outputs are programmed as On/Off. I'm using the K3 clone function, and then OUT0 is hard-configured but OUT1 and OUT2 are available.

I don't want to expose the web interface of the RRC to the Internet. So much is happening via HTTP these days, and the RRC doesn't do encryption. Operating the web-interface via a tunnel is possible, but if all I need to do is set or reset an output, then a simple shellscript on a raspberry is just as well. How to operate the web-interface via a shellscript?

Some experimentation learns that to switch-on OUT2, you can use something like:

  wget -q  --post-data 'out2Mode=4&out2OnOff=OFF' --output-document /dev/null http://IP.AD.DR.ES/settings


Note that ON and OFF are reversed, so out2OnOff=OFF switches the port ON, and out2OnOff=ON switches the port OFF.

To switch port1 instead of port2, change 'out2' to 'out1' above.

If your RRC is password-protected, you need to add:

  wget -q  --user USERNAME --password PASSWORD --post-data 'out2Mode=4&out2OnOff=OFF' --output-document /dev/null http://IP.AD.DR.ES/settings

Again, the RRC web interface probably should not be directly connected to the Internet anno 2024; the web password is trivial to decode from the web traffic. If you can run this via SSH on a raspberry, then perhaps that is a better choice.

73, Geert Jan

2
Feature Requests / RRC1258 status page: output status issue
« on: 2024-04-17, 20:25:27 »
(for reference: RRC1258 version 7, software 2.95)

I think I found an issue with the RRC1258 status page which I have not seen reported on the forum, so I'm calling it in:
I think the status for Output 1 and Output 2 are reversed on the Status page.

How to repeat: configure Output 0 and Output 1 as Connect, Output 2 as On/Off.
Do not connect to a control-RRC and leave Output 2 as Off
Go to Status page and notice that all outputs report as status Low.

On I/O settings page, flip Output2 to On. Notice that the OUT2 On/Off indicator is now green ("ON").
Go to Status page and notice that Output1, not Output 2, reports as high.
That is wrong: Output2 should be reported High, not Output1.

On I/O settings page, flip Output2 back to off. Notice that all outputs now report Low.

Connect a control RRC. When the connection is up, OUT0 and OUT1 will activate.
However, when checking the Status page, now Output2 reports as high and that should be Output1.

This isn't the end of the world but I found it when building scripts. Separate message about that.
I'm surprised this wasn't reported before though.

73, Geert Jan PE1HZG

3
Would be interested (in the forum) to see your finding from the site visit. One possibility: if there is RF with the TUNE button, then perhaps MENU:MIC SEL is set incorrectly. Don't ask how I suggest this ;-)

4
You don't need to make the HTTP port accessible from the Internet at all for remoterig to function. Once set up, you don't need access to the HTTP port from the Internet; only the UDP ports are required.

Also, I wonder how the remote is accessing the network. If you're using some kind of access point, perhaps as wifi client (which is not unlikely given the unavailability of the wifi module these days), you might want to ponder using said access point to create a VPN tunnel and only make your remoterig accessible via the tunnel. I would do some experiments with OpenWRT for this.

Alternatively, if the control station is at a fixed location (hence has a predictable IP address), you can limit access from the internet to only accept these predictable IP addresses. That is trivial (at least on OpenWRT).

If you DO need HTTP access, another possibility would be to make an SSH connection to a raspberry pi, enable SOCS on the SSH connection ("ssh -D 1080 ....") and then temporary enable SOCS on your firefox browser and use that to access the HTTP port. Note that you can't use SOCKS to tunnel the UDP connections but HTTP should work.

5
Configuration, RRC 1258 / Re: Use of Line In/Line Out on K3
« on: 2023-11-28, 14:44:06 »
Addition (sorry!):

remoterig K3 twin audio volume control works by having the volume pot settings transferred to the radio K3, which is then used to change the audio volume on the radio K3, hence also changing the audio volume on the control side.

However, changing the volume does not change the output level of the line out port. Hence, "volume control" will not work if you use line out, unless you provide an alternative means for volume control on the control side (an audio amplifier with an audio pot connected to the control box).

But keep in mind that "AF gain does not work" if you do line-out instead of the prescribed speaker out / headphone out.

Geert Jan

6
Configuration, RRC 1258 / Re: CW sidetone too loud
« on: 2023-11-26, 16:44:19 »
I think you have a double problem.

The SP port is intended for a loudspeaker and can drive enough volume for that. Since sidetone is generated locally, you (can) get quite some audio volume.

You can turn the audio volume down (which I expect you have done), but if something happens that will make the speakers do full drive then the volume can be ear splitting and actually cause ear damage.

I made a small jumper cable with 2x 150E resistors in series with the headphone (one on each channel). Now sidetone volume is OK and my ears are protected.
The "150E in series" is what makes an hearphone port, and earphone port. Just look at any radio schematic.

73, Geert Jan PE1HZG

7
Configuration, RRC 1258 / Re: WEB Site not reachalbe
« on: 2023-11-26, 16:38:20 »
The web server works find on firmware 2.95, used it 10 minutes ago. However, some browsers these days either default to HTTPS traffic or only allow HTTPS traffic, which the RRC does not do (doesn't make sense either, so there).

So ensure you access via http:// and not https://

Geert Jan

8
Configuration, RRC 1258 / Re: Use of Line In/Line Out on K3
« on: 2023-11-26, 16:35:31 »
It "kind of works" but you will loose quite some K3 functionality.

For one, the "AFX spatial sound" feature is only available via the headphone / speaker output, not via line-out. You will lose AFX if you interface using the line ports.

Secondly, if you have the subreceiver option, note that there is a hard relationship between these receivers (main/sub) and the line out port.
If you switch off your sub receiver, the K3 will drive both audio channels (if you're using the headphone port, or of you are using the speaker port and have set the number of speakers correctly).
Not so for the line out port: one "audio channel" will go silent.

The way I've "solved" this is to use the headphone port on the back and switching the internal speak on and off using the CONFIG:SPKR+PH setting, which i have assigned to one of the programmable buttons on the front: press the button and the setting toggles and switches the radio speaker on and off.

I used another programmable button to access the MENU:MIC SEL menu. This way I can switch between the mic port on front (when I operate at the radio location) or the mic port on the back (when I operate via remoterig).

I had to play with the gain settings to make the headphone port work.

73, Geert Jan

9
Let me reply to my own posting to document how this all worked out.
While there was no response on the forum, Mike did immediately respond when asked directly, thanks!

It turns out that OUT0 is "hard coded" to do the Connect function when using mode 14 (Elecraft twin). You can set OUT1 and OUT2 any way you want (duplicating the Connect function, if you want), but OUT0 is always Connect. Hence, it is not possible to free it up; it is possible to set OUT2 also as Connect but I would lose one OUT port which is not what I wanted.

I "solved" the issue by making a small cut in the cable going tot the I/O connector and using that to splice off the OUT0 signal for the K3 DB15 connector.
Not entirely clean but I was able to make a reasonable solution with some heat shrink tube and I made my own cables anyway.

However, I was still able (using the same I/O cable) to get access to OUT1 and OUT2 and use them to "switch something else". Each of those now drive a solid state relay (Carlo Gavazzi RP1A23D5, but there are many alternatives) and I can switch-on and switch-off power supplies and the like at the radio location to save energy, which was the original plan.
(I need the I/O connector for that because the OUT outputs switch to ground and I needed the 8V output to drive the solid-state relay between).

I also made another "electrical power switch box" that uses the 12V DC output of the K3 to switch more stuff. Now, OUT1 and OUT2 switch some parts of the remote station and my transverters et all power-up if the K3 is switched on.

While I would have preferred to use the PAD port for K3 power control, the issue is minor and at the remote radio end. So it goes,

Geert Jan

10
Configuration, RRC 1258 / Problem saving settings on v2.95
« on: 2023-10-25, 01:21:18 »
When using the RRC's in "Elecraft twin mode", OUT0 is used to pulse-on the remote K3 when the control K3 is powered up.

To that end, OUT0 should be configured for Connect and a cable is documented the I/O connector to the DB15 connector on the Elecraft.

I would like to use the I/O connector to control some optocouplers. I prefer to use the I/O connector because it provides 8V so I can use the open-drain output of OUT0 and OUT1 against the 8V to drive said optocoupler. The K3 poweron pulse is against ground.

The PAD connector also provides OUT2 and OUT1, and ground. I should be able to use OUT2 for the Connect power-on pulse. so I can free up the I/O connector.

To that end, I have configured OUT2 for Connect so I can use the tip connection of the PAD connector and GND since the K3 power on only needs a GND connection and an output pulsing to GND.

That works: I changed the RJ45 connector to a 3.5mm for the PAD connector (tip to K3 DB15 poweron, shield to K3 DB15 GND).
I tested this and the remote K3 correctly powers-up with the new cable to the PAD connector.

I now have the I/O connector off and should be able to use OUT0 and OUT1.
I set OUT0 and OUT1 to On/Off and I am now able to control a LED remotely.

However, when I save the config (apply changes) then the OUT0 connector changes back from On/Off to Connect.

Is there any way to avoid OUT0 switching back from On/Off to Connect?


11
Hi,

Perhaps to inspire others:
I am preparing for the annual Jamboree-on-the-air in october where Scouts make radio contacts to other Scouts via amateur radio. JOTA is big in the Netherlands with typically 175 stations active, and the 2m FM frequencies very busy (the 145.500 calling frequency being congested so much that you can't call CQ w/o having a QSY frequency ready, because someone else will call CQ while you try to go QSY).
Obviously a lot of new hamradio operators with perhaps sub-optimal operating practice, but in my group we have half a dozen of scouts with hamradio licenses with another four currently going through the paces of getting their license. A lot of energy and enthusiasm ongoing.

I have trouble because one can't really run two 2m stations on the same location because transmitters will block and I have enough scouts that want to make radio contacts that running two stations is desirable. So, I'm planning to run an experiment with a pair of RRC1258's to remote an FT7800 where the head of the radio is at Scouting but the radio unit itself is in my shack, connecting to my antenna.

Long introduction, and there is a catch: we normally operate using headphones to control the amount of local QRM in the JOTA radio shack. We find that Scouts are much better able to participate if the audio quality of the radio connection is good, and headsets are preferred above a room with speakers shouting.
However, when using headsets with a group, it is very nice to have a "monitor feature" so when someone is speaking while transmitting, other scouts will hear what is being transmitted to the other group.

The FT7800 does not provide this monitor feature. It was not hard to find points in the RRC1258 for microphone audio and speaker amplifier input to add a monitor feature, but the microphone is enabled all the time (at least in the points I found) and there is no PTT signal in the RRC1258 control unit.
I asked Mike and he confirms - the PTT signal is (only) in the serial data stream between head and radio and there is no logic signal in the control RRC to conditionally feed audio from mike to speaker, only when the radio is transmitting. Unfortunately, Mike agreed with my finding. What to do?

Pondering on the problem a bit, I think I now found a solution. The radio RRC can have one its outputs on the I/O connector configured for "PTT". And it is possible to use the I/O feature of the RRC pair to move a logic signal from the radio-RRC to the control-RRC.

In my lab, I now tried this:
  • On the I/O connector of the radio RRC, I installed a "loopback plug". The loopback plug has pin 6 (OUT1, open collector) and pin 2 (IN2) connector together, and the junction connected via a 10K pullup resistor to pin 7 (8V out)
    Update: looking at the RRC schematics, probably don't need the pullup, just loop 2 and 6 togther
  • On the radio RRC, I configured OUT1 to be used as PTT signal. The PTT signal is now transferred via IN2/OUT2 to the control RRC
  • On the control RRC, I connected pin 3 (OUT2, open collector) to a pull-up resistor to pin 7 (8V out)
  • On the control RRC, I configured OUT2 to use I/O, so it is tracking the IN2 input from the radio RRC

Voila. I now have a logic signal that activates if the PTT line is active. Now what is left is to feed the microphone signal via a 4053 switch to the input of the audio amplifier.

But I though that bringing the PTT signal to the radio RRC this way was unusual and worth reporting about.

Geert Jan

Pages: [1]