[Hamlib-developer] Problem with rotctl

[Erick Schumacher]

Hello Team

I am trying to connect a Yeasu GS232B rotor controller to G predict. Using
rotctld Gpredict does not always report the correct az and el direction. I
am running XP. The rotor has the proper response to commands when sent from
a terminal. The rotor responds correctly when queried by rotctl with
commands B and C. When sent command p I get get incorrect az and el values.
Below is a screen copy of my XP CMD window.

Report bugs to <hamlib-***@lists.sourceforge.net>.

C:\Program Files\hamlib-win32-1.2.15.3\bin>rotctl.exe -m 603 -r COM4 p

35.000000

3.000000

C:\Program Files\hamlib-win32-1.2.15.3\bin>rotctl.exe -m 603 -r COM4 w B

EL=012

C:\Program Files\hamlib-win32-1.2.15.3\bin>rotctl.exe -m 603 -r COM4 w C

AZ=035

C:\Program Files\hamlib-win32-1.2.15.3\bin>rotctl.exe -m 603 -r COM4 w C2

AZ=035EL=012

The actual setup string used with Gpredict is C:\Program
Files\hamlib-win32-1.2.15.3\bin>rotctld.exe -m 603 -r COM4 -T 192.1.102 -t
4533

Using rotctld Gpredict reports az and el values similar to the p response.
Above I used rotctl just because it is more convenient, I assume that the
responces are similar. Where am I going wrong?

A second question is what command elicits az and el information when
easycomII ( rig# 202) is polled with a p command.



73 WB6KCN

[Nate Bargmann]

Post by Erick Schumacher
Hello Team
I am trying to connect a Yeasu GS232B rotor controller to G predict. Using
rotctld Gpredict does not always report the correct az and el direction. I
am running XP. The rotor has the proper response to commands when sent from
a terminal. The rotor responds correctly when queried by rotctl with
commands B and C. When sent command p I get get incorrect az and el values.
Below is a screen copy of my XP CMD window.
C:\Program Files\hamlib-win32-1.2.15.3\bin>rotctl.exe -m 603 -r COM4 p
35.000000
3.000000
C:\Program Files\hamlib-win32-1.2.15.3\bin>rotctl.exe -m 603 -r COM4 w B
EL=012
C:\Program Files\hamlib-win32-1.2.15.3\bin>rotctl.exe -m 603 -r COM4 w C
AZ=035
C:\Program Files\hamlib-win32-1.2.15.3\bin>rotctl.exe -m 603 -r COM4 w C2
AZ=035EL=012
The actual setup string used with Gpredict is C:\Program
Files\hamlib-win32-1.2.15.3\bin>rotctld.exe -m 603 -r COM4 -T 192.1.102 -t
4533
Using rotctld Gpredict reports az and el values similar to the p response.
Above I used rotctl just because it is more convenient, I assume that the
responces are similar. Where am I going wrong?

Hi Erick.

So far things look good, although I am not familiar with the GS232B
native command set. I trust that the rotor's raw B and C commands are
reporting the correct data and 'p' is not?

Please try this:

Run rotctl in interactive mode with tracing enabled:

C:\Program Files\hamlib-win32-1.2.15.3\bin>rotctl.exe -m 603 -r COM4
-vvvvv

At the prompt enter 'p', then 'w B', and 'w C'.

If you don't see a difference between the raw data from the rotor, then
it is probably a backend bug.

Post by Erick Schumacher
A second question is what command elicits az and el information when
easycomII ( rig# 202) is polled with a p command.

I'd have to go and read the backend source and get back to you. It may
be a while as I am moving and not spending much time in front of a
keyboard for a few weeks.

73, de Nate >>

[PB0NER de Martijn]

Hi all,

Not long ago I mentioned my Ethernet equipped Yaesu rotor controller which can be build cheaply (around us$ 20 in parts) and got some positive feedback. I can now announce the same for Icom CIV and Yaesu CAT. I have support for the Icom 910 and Yeasu ft-900 since that are the radio's I have.

Although in C I have not used any line of Hamlib code and have a different kind of abstraction layer for CAT and CIV commands so it will be fairly simple to implement other yeasu radios, and the same for CIV equipped Icom radio's.

There are several advantages to my approach giving all the equipment an Ethernet port. The main one is isolation. But there is also no need for serial/sub ports.

On the Ethernet side these little interfaces talk the Hamlib protocol and I have not tested every piece of software, gpredict runs absolutely fine to rotor and ic910. My Yeasu ft-900 software talks Hamlib but I have written my own objects to talk the protocol.

All the prototyping has been done and I am in the process of pcb design. It will be low power little boars with the smallest SMD components possible. My G5500 powers the rotor controller and my 910 the interface.

Next up will be a USB to Ethernet module. For all the legacy software which wants a serial port. It will translate GS232 to Hamlib for instance. This module might end up slightly more costly.

Just point at me and shoot: question, interest, anything as I want this for my own purpose and I am not sure what to do with it to the general public. I can open-source it, produce it or both..

Do you want something similar for your rotor/radio? Etc.

73's PBØNER
Martijn

[PB0NER de Martijn]

Hi Tony,

These interfaces are small ATMEL devices with an ethernet chip attached to the SPI. They are compatible with Hamlib as they emulate rotctld/rigctld. Although I use the hamlib sources as a reference, I am not really using any code since there is not enough RAM or program memory available. Look at it as protocol compatibility.

My rotor controller is fully functional and plugs straight into any Yaesu rotor. I am using my G5500 with gpredict for testing and that works fine. There is no need for any additional hardware and the interface is powered from the rotor controller. In total it is an Atmel, a Crystal, a few Capacitors, four FET's a few pin headers, a 78L05 and a pcb is drawn up at the moment. The ethernet part is a small pcb so cheap I did not bother to integrate that on the PCB. The rest is done by software on the atmel.

The RIGCTLD variant is about the same, except for the FET't. It has been prototyped on a IC910 and Yaesu FT-900 as I have these radios. Both have a serial interface. Where the IC910 is CIV and there is again no need for additional hardware. The ft-900 has a TTL CAT serial. And the only difference is the cabling to the radio. Both these radio's support PTT by software. But there is support for a hardware PTT (using a FET).

I am not sure what to do with the audio yet. Since I want it all to be compatible with as many existing options and software. I might end up using Bluetooth audio but I have not done any work on that.

It has all been prototyped and functional. I did send word around for additional input.

Another thing I have worked out is the same thing, but a bit different. That is based on a Raspberry Pi the interfacing done to the rotors/rigs is done over I2C. I am planning on implementing that in the real hamlib sources, where I replace the /dev/serial to /dev/I2C ..
Each rig or rotor will have its own little adapter on the I2C bus and multiple rigctld/rotctld will run on the RPi's Ethernet interface. The PCB's will be the same as the Ethernet versions. Just leave out the Ethernet, and connect I2C. Firmware will be different.

Questions and remarks are very welcome. I have not yet published anything on my site/blog yet as I want to have production PCB's for the pictures.

I am planning more stuff, like controlling coax relays, SP5055 pll's for ATV. And more rotors (even without a computer interface). These will be interfaced hamlib wise on protocol level.

Verstuurd vanaf mijn iPad

Post by PB0NER de Martijn
Hi all,
Not long ago I mentioned my Ethernet equipped Yaesu rotor controller which can be build cheaply (around us$ 20 in parts) and got some positive feedback. I can now announce the same for Icom CIV and Yaesu CAT. I have support for the Icom 910 and Yeasu ft-900 since that are the radio's I have.
Although in C I have not used any line of Hamlib code and have a different kind of abstraction layer for CAT and CIV commands so it will be fairly simple to implement other yeasu radios, and the same for CIV equipped Icom radio's.

Hi. :)
For some reason, Google decided that your message was spam, so I missed seeing this until now. This sounds like a very interesting development. I'm keen on making my radios as network connected as possible, and would be interested in learning more about your interfaces. This will go well with my general plans to migrate from PC based control to a more network oriented approach, where different components of my setup are separate, but are linked by the network. It might also make my IC-7000 more accessible to my non Windows machines.
Can you tell me more about your interfaces?
--
73 de Tony VK3JED/VK3IRL
http://vkradio.com

[PB0NER de Martijn]

Verstuurd vanaf mijn iPad

Post by PB0NER de Martijn
Hi Tony,
These interfaces are small ATMEL devices with an ethernet chip attached to the SPI. They are compatible with Hamlib as they emulate rotctld/rigctld. Although I use the hamlib sources as a reference, I am not really using any code since there is not enough RAM or program memory available. Look at it as protocol compatibility.

Cool, I have had some success with rigctld, I have used it to access the IC-7000 over the network, though that currently means leaving the Windows box running.

Indeed, there is a raspberry pi possibility, lower on power. Linux skills are needed though

Post by PB0NER de Martijn
My rotor controller is fully functional and plugs straight into any Yaesu rotor. I am using my G5500 with gpredict for testing and that works fine. There is no need for any additional hardware and the interface is powered from the rotor controller. In total it is an Atmel, a Crystal, a few Capacitors, four FET's a few pin headers, a 78L05 and a pcb is drawn up at the moment. The ethernet part is a small pcb so cheap I did not bother to integrate that on the PCB. The rest is done by software on the atmel.

Cool, though I don't have any rotators.

I am into satellites so I have to rotate..

Post by PB0NER de Martijn
The RIGCTLD variant is about the same, except for the FET't. It has been prototyped on a IC910 and Yaesu FT-900 as I have these radios. Both have a serial interface. Where the IC910 is CIV and there is again no need for additional hardware. The ft-900 has a TTL CAT serial. And the only difference is the cabling to the radio. Both these radio's support PTT by software. But there is support for a hardware PTT (using a FET).

I have an IC-7000, which speaks CI-V, but each radio does have individual variations in their command sets. My other radio would need a custom version written for it, it's an FT-736R, and Hamlib is one of the few options that supports a radio this ancient. However, I currently have it connected to a Linux box and running as a remote base (which is of my own creation - see http://vk3jed.vkradio.com for more information), so it's covered for now. :)

I have organized my stuff a bit different internally. Everything is highly object based. Implementing other civ radios is relatively simple. I'll have a look at your site. I think the ft736 implementation would not be much of a problem. Are you capable of programming in C?

Post by PB0NER de Martijn
I am not sure what to do with the audio yet. Since I want it all to be compatible with as many existing options and software. I might end up using Bluetooth audio but I have not done any work on that.

OK, I would be needing a multipoint capable means of audio distribution, so I could leave multiple PCs connected, and use the one I need at the time. Not sure if Bluetooth can do this, I've only seen it used point to point (via pairing), which would be problematic for my uses.

With bluetooth audio will be distributed from the connection point. It will be just another audio device, like an usb sound card.

Post by PB0NER de Martijn
It has all been prototyped and functional. I did send word around for additional input

Well, if there's anything I can offer, I'd be happy to. I've been frustrated by the state of rig control, being so PC centric. That is a majoy handicap in an environment like mine, where I demand flexibility without plugging and unplugging cables (I may want to do the switch remotely via software, or even share the radio). Your work is definitely a small step in the right direction as far as I'm concerned.

There will be more, as I want everything web based. HTML5 and stuff like websockets. It will be activity based and it locks devices for that activity. Basically I want to end up making QSO's from my iPad or iPone. I have some stuff made up and working my sat tracking software is showing realtime info, like the frequency of my radio. The back-end is pure Python.

Post by PB0NER de Martijn
Another thing I have worked out is the same thing, but a bit different. That is based on a Raspberry Pi the interfacing done to the rotors/rigs is done over I2C. I am planning on implementing that in the real hamlib sources, where I replace the /dev/serial to /dev/I2C ..
Each rig or rotor will have its own little adapter on the I2C bus and multiple rigctld/rotctld will run on the RPi's Ethernet interface. The PCB's will be the same as the Ethernet versions. Just leave out the Ethernet, and connect I2C. Firmware will be different.

That could be interesting too. :)

With Ethernet everything is electrically apart as there is a transformer. I do like that. Another idea might be rs-485 with optocoplers.

Post by PB0NER de Martijn
Questions and remarks are very welcome. I have not yet published anything on my site/blog yet as I want to have production PCB's for the pictures.
I am planning more stuff, like controlling coax relays, SP5055 pll's for ATV. And more rotors (even without a computer interface). These will be interfaced hamlib wise on protocol level.

Yep, all good.
--
73 de Tony VK3JED/VK3IRL
http://vkradio.com