Setting up preset search on your Gateway using Wires-X version 1.22

Setting up preset search on your Gateway using Wires-X version 1.22

Hotspots & Fusion / Wires X

Hotspots & Fusion / Wires X

Intro to System Fusion and Wires-X Integration from HamCom

Intro to System Fusion and Wires-X Integration from HamCom

HRI 200 with No RADIO's

Wires-x without a radio HRI 200 with No RADIO's

#hamr #amatureham #amateur radio

[YaesuSystemFusion] What does the HRI-200 actually do ?

I'm trying to work out what the HRI-200 is actually doing.

Fusion radios already contain a CPU, audio ADC/DAC's, a C4FM modem, AMBE+2 vocoder, a DSP (operating as the C4FM mode and vocoder) and a serial communications port for direct connection to a PC.

I could understand having a unit like the HRI-200 IF it had a network port on it that allowed it to act as a stand alone bridge between the radio and the Yaesu internet based network system. But no, a constantly connected and running PC is requi
red to act as the internet-interface/bridge/radio-controller etc, which of caused can already be plugged directly into the Fusion radio without the need of a seperate box (the HRI-200).

So what actually is the HRI-200's role in all this, what is it actually doing that the Fusion radio and PC alone couldn't already do as a pair ?

[YaesuSystemFusion] Constant WiRES-X Node Lockups [FIX]

This issue has been happening since the v1.10 WiRES-X software release; however, it has become increasing worse, even with the latest v1.11 release.

Today alone the node has locked up a 1/2 dozen times or so, while using the FTM-400DR as a link radio pointed at the repeater and connected to the "AMERICA-LINK" room.  We've now turned it off...

The lockup holds the FTM-400DR in constant transmit with no audio, no call sign data, and the hardware time out timer isn't shutting down the radio either, which keeps this hung transmitter open well past the allowed 3 minutes per FCC rules.  This morning, the transmitter was hung open for 1 hour the first time, 45 minutes the second time, and so on...  The radio, even-though it's only 5-watts is getting hot and I fear the finals will surely be burned up as these radios are not designed for this kind of work; even with that stupid fan accessories Yaesu want's to sell us.

Yaesu, if you are "TRULY" listening, we know this issue has been reported on numerous occasions, we even emailed you directly with the details you requested.  This issue MUST be fixed A.S.A.P.  If it's not going to be fixed in the next few weeks, then I fear this is the end of Yaesu System Fusion for us, as we are NOT going to continue pumping money into Yaesu test bed.

Respectfully, we request an immediate resolution to the hung transmitter issue, at the very least, a watchdog timer should be making sure the radio isn't hung in TX past the allowed 3 minutes

[YaesuSystemFusion] HRI-200 Schematic

HRI-200 Schematic

Looking for a schematic diagram for the HRI-200 to verify signal names
and pinouts of the rear panel connectors.

I've been searching the 'net but have come up empty so far.


YAESU Fusion WIRES-X HRI-200 connected
HRI-200 connected

YAESU Fusion WIRES-X HRI-200 connected

YAESU Ham Radio University 2016

Ham Radio University 2016
Pretty good video on digital modes.  In beginning Yaesu give good talk on Fusion and the products.

[YaesuSystemFusion] Re: Wires-X to Linux

First of all, Yaesu will never produce a Linux version of WiRES-X. I don't think we want them to. I suspect we'd rather add features and fix bugs rather than giving us a different version of a capability we already have. Personally, I want to see the API for the WiRES-X software. When we can't that we can have plenty of fun!
The existing WiRES-X software will never run on a Raspberry Pi or anything that doesn't use an x86 style CPU. The code is compiled for Intel, so it will never run on ARM.

I disagree with your assumptions here.  Code can be written using multi-platform toolkits that effectively makes the application natively available for Windows, Mac, Linux, etc.  How difficult this is to support depends on what the original language software was written in.  Btw.. there is ZERO reason why Yaesu couldn't cross compile their existing code to say ARM and run it on say a Rpi2 running Windows10 IoT (this MS OS exists today).  I don't know if an Rpi2 has the system resources to support Wires-X's needs (is Wires-X written to use SMP to distribute it's CPU needs vs. being single threaded) but there *are* options here.

I have heard rumors that it's possible to get the WiRES-X code on Linux running under Codeweaver. Code weaver provides .NET and Win32 support. It's paid software, but that means you get professional support and it's constantly being updated to make more Windows software run on it right out of the box.

(If you're invested, get the 14-day trial. Wait. Don't buy it. Wait longer. You will eventually start getting discounted offers.)

It would seem like a good "open source" project to port WiRES-X under Codeweaver. I for one would rather run it in a Linux (Ubuntu) environment. No Windows license needed. And with WinX on the horizon, I'm now thinking I like the idea of Windows even less.

If it was written in .NET or C#, there is a chance this will work under Wine (open source direct relative of CodeWeaver) or even natively under Linux since MS has open sourced their .NET code.  It's unclear to me if the Mono community is going to absorb this code or if some new project will emerge to support it but I think this was a smart move by MS though very very late.