Not yet as none of the core team own any of the new batch of Yaesu radios. One of the major advances with the release of wfview v2.00 is that the new rig interface will allow drop-in replacements for the Icom parser to allow support for other protocols.
Kenwood is likely to be the first to be supported (mainly because I one a TS-590 and a FlexRadio 6500, both of which use the Kenwood protocol, but if we are able to get hold of suitable Yaesu hardware… who knows (any donations gratefully received )
Thanks for the reply.
I will tranlate these information to other forum to make more ham friend to learn more.
I hope more and more ham can use wfview which is a nice software in the future.
Recently, I came across software designed to control Yaesu radios, specifically the FTDX10, FT710, and FT101. It seems to share some similarities with WFVIEW in terms of functionality. Since I am not a software expert, I am not able to deeply analyze or compare them, but I believe this information might be helpful for the WFVIEW development team, especially for exploring future support for Yaesu radios.
Here is the website for the software:
I was wondering if this could serve as inspiration or a resource for developing a Yaesu-compatible version of WFVIEW. Do you think WFVIEW for Yaesu radios, such as the FT710, could become a reality in the future?
Thank you for considering this suggestion, and I look forward to hearing your thoughts!
I’m interested in tinkering with this for my own new FT-710. So far I have that:
The USB CAT interface is documented, although the SCU-LAN10 interface is not
The scope interface does not use the COM ports, it uses something else. It’s mostly cracked.
From a quick look at the computer control software for the SCU-LAN10, it looks like the CAT part is essentially piping the regular CAT commands over. There are separate functions to send/receive scope data. That would line up with it being the I2C interface. I can also try pulling apart the software BG2CTX posted.
Ideally, I feel like wfview should support both the SCU-LAN10 interface and the USB interface. This should be doable; it seems like people who have more skills than me have already figured out most of what’s needed. I’d be interested in helping out, if possible.
Are you OK with me reverse-engineering the PC control software and posting findings from that, or do you want this to stick to looking at traffic over the wire?
msgId is one of the following values, with R2C meaning “SCU/radio to computer” and C2R meaning “computer to radio/SCU.” The C2R values are not necessarily exhaustive:
MSG_C2R_LOGIN = 0x101;
MSG_C2R_LOGOUT = 0x102;
MSG_C2R_OPEN = 0x103;
MSG_C2R_CONNECT = 0x104;
MSG_C2R_DATA = 0x105;
MSG_C2R_HEALTHCHK = 0x107;
MSG_C2R_UNK_RATE = 0x108; // Used by SendCatRate, not sure what it is more generally
MSG_R2C_LOGIN_ANS = 0x181;
MSG_R2C_LOGOUT_ANS = 0x182; // Probably
MSG_R2C_OPEN_ANS = 0x183;
MSG_R2C_CONNECT_ANS = 0x184;
MSG_R2C_DATA = 0x185;
MSG_R2C_CLOSE_ANS = 0x186;
MSG_R2C_HEALTH_ANS = 0x187;
Also, the software seems to make 4 separate connections to the LAN unit on different ports: one for control (i.e. DEV_LAN_UNIT), one for CAT (it uses DEV_USB_CAT, at least on the copy of the software I’m using), one for audio (again, my version uses DEV_USB_AUDIO), and one for scope (which the software calls dinspi).
CAT seems to use the standard CAT commands in ASCII text; there are some undocumented “binary commands” that are radio-specific and get passed to the SCU unit on login, but I don’t see them actually being used (they seem to be raw memory read/write commands). Scope data, still looking at, although I strongly suspect it’s nearly identical to the raw data being read over USB. The basic flow seems to be:
Set up connections to the SCU on 4 ports: SCU control, CAT control, audio control, scope. These are user-configured, but defaults are in the SCU installation manual.
On SCU control, send a login message (which just has the username and password in plaintext). The response will include a session ID value, which is used to authenticate on most later commands.
Send some data on SCU control to set up some binary radio-specific undocumented CAT commands that I’m not sure this software ever actually uses.
Send “open” commands on the remaining 3 ports (for CAT, also specify the data rate).
Send “connect” commands on the remaining 3 ports
Use the ports to send/receive CAT, audio, and scope data. Send heartbeats every so often.
EDIT 4/8 (I can’t make another new post because I’m a new user):
Audio seems to be raw PCM data or ulaw-encoded PCM data; when it’s ulaw-encoded, PCM values are first divided by four before encoding (or multiplied by four after decoding). I don’t see any command to set audio format, although on initial connect the software sends a null audio wave with its parameters set according to the config file. I can only assume the SCU unit then uses those parameters for audio being sent to the computer. Audio quality is a sample rate of 16000 or 8000, and ulaw either on or off.
I should probably make a header file with packet formats. I think I have most of them that are used by the main operating software (I haven’t poked at the config software yet), but I’m still trying to figure out the raw scope data. It’s not parsed in the DLL handling comms, or in the .NET executable that’s the main program. It’s instead passed off to a drawing helper DLL, which I’m trying to understand but is somewhat more confusing.
This is excellent and it looks like enough information for us to add support for these Yaesu radios.
But we will need a radio to test with, either on loan or donated. I doubt we can get too far just by blindly coding it in there. It’s also possible someone could setup a development computer locally, that might help get things started.
Your wfview team has… many radios. I would say “too many” but I’m not sure that’s possible :). But somehow not any recent Yaesu rigs.
Anyway, this will be a good topic to consider seriously after we get our next release out, which has a good many bug fixes and preliminary Kenwood support.
I’d be willing to help with the programming. I don’t own an SCU-LAN unit, and to be honest a big part of my goal is to remove the need for me to buy one. However, I also plan to work on the USB protocol with the FT-710 I do own and see if I can code up a translator unit that works with the stock remote control software (which as a bonus, should be way less tedious because I don’t need to define the meaning of every single CAT command — the only converting would be audio and possibly scope data). If I can do that, I could use it as a basis to try and develop something that should work, at which point I could hand it off to someone who does own the SCU to test it with the real hardware.
If I can’t figure out how to make a converter of my own, I’ll probably just buy the real SCU and can then develop against that and/or help you guys develop against that.
Okay - I’m not sure how @ratmandu came up with his numbers for SPI scope data, but changing them to waterfall lengths of 850 and FFT lengths of 200 seemed to produce decent results too. Those values line up with the network scope packets:
struct AudioData {
byte FFT[200];
byte OSC[400];
};
struct ScopeFrame {
byte ScopeA[850];
byte ScopeB[850];
AudioData AudioA;
AudioData AudioB;
byte[0] AdditionalData; // Unclear how much there is of this
};
With that, it looks like the USB interface and network interface are virtually identical for both CAT and scope. Audio network is PCM with optional ulaw, which I’m not an audio guy but as I understand it raw PCM can be directly written to a USB audio device (which would mean the only processing needed on the LAN unit is ulaw). There’s also the controls for the LAN unit itself, which I still need to sort out, but it feels like there’s very little processing done on the LAN unit and wfview support for LAN and for USB would be essentially the same task.
While I figure out where to start coding, I want to ask: does wfview support audio oscilloscope and FFT display, or just spectrum scope?
We do plan to support audio scopes for the radios that have them (such as the Kenwood TS-890). And eventually we may just perform the DFT locally and provide it for other radios as well.
I was basically figuring it out visually, by plotting the data using Python and guesstimating where the edges were. Thanks for the clarification and figuring out a lot more than I was able to. Project has been on the back burner for me as I’m waiting to purchase a LAN unit for my DX10, as that normally sits on my desk while the 710 is my dedicated POTA rig.
If I can find out what the LAN unit sends to the DX10 to get it to start spewing data, I can start on this again, but money is tight at the moment, so that purchase will need to wait. I do already have an ESP32 hooked up to the ACC port on the DX10, ready to start pulling data and sending over the network, but as of yet, I haven’t been able to trigger the DX10 to send that data out.
I’m possibly getting ahead of myself, but as I work on this LAN<->USB module I’m also thinking about how I’d ultimately integrate processing into wfview. It seems like rigCommander is what I’d want to extend to handle a Yaesu radio, as it currently handles Icom and Kenwood.
For audio, I should keep in mind audioPacket, because that’s what wfview’s existing audio handling uses everywhere. There are a couple of quirks of the FT-710 that wfview doesn’t support, like the ability to have separate receive and transmit buffer sizes/latency. I probably don’t have to worry too much about how to support that, and if I convert from audio packets over the wire to audioPacket I can pass it off (somehow) to the built-in audio handler code (which I could set to output to USB audio to talk to the radio, or to speaker to play for the user). Not having easy time difference control, I’d just use received time for audioPacket.time.
For UDP, it looks like udpBase and things derived from it embed a fair number of assumptions that this is using the CI-V protocol. commHandler likewise seems to embed assumptions that it’s CI-V in its receive validation. I should expect to write my own UDP handlers for CAT, audio, and scope, both server-side and client-side, as well as USB handlers for audio and scope. yaesuCommander would then construct these handlers as appropriate, and implement rigCommander functions. I’m not actually sure where CAT commands are constructed, though – that would need modification for Yaesu. Some of the rigCommander members are also not quite sufficient for the purpose here, like udpPreferences having only 3 ports (Yaesu needs 4, since scope is its own port) and commSetup for local radios not including any specification that could lead to the scope port. Obviously, setCIVAddr would be useless on a Yaesu.
Anything else obvious I’m missing? I’m not sure how wfview implements its server mode, although linking slots on the comms handlers to slots on a server would seem to be the obvious approach.
Does anyone know how the stock SCU-LAN behaves if multiple people try to connect at the same time? Does the most recent connection win, or does the oldest connection win, or does it somehow support both?
EDIT: For an Icom 705, apparently the second and subsequent connections fail with an error. For a Flex, apparently you have an option to kick off the existing session and take over. Not sure what wfview itself does. I’d normally be inclined to make the newer session automatically kick off the older one, actually.
wfview allows for multiple concurrent connections, but I think only the first can transmit. It’s been a while since I experimented with that.
The Icom radios, as far as I have seen, only allow one user at a time. Attempts at concurrent connections will send the second user a note of what user and IP address is occupying the radio.
I have yet to try a concurrent connection on my Kenwood TS-890. But my guess is that it will fail to connect.
I think if you can support concurrent connections you should, but it’s probably not a big deal to most people.
)