<div dir="ltr"><div class="gmail_default" style="font-family:garamond,serif">Hi Alf,<br></div><div class="gmail_default" style="font-family:garamond,serif"><br>The current discovery implementation is limited. Not having a Metis or multiple SDR's to observe, I couldn't work out 100% what was really supposed to happen in practice, so thank you for your insight!<br></div><div class="gmail_default" style="font-family:garamond,serif"><br>The libusb does have to be there. Again, from memory there are a couple
of libusb's and if you follow the info found in ghpsdr3-alex you should
be fine. After finishing I
recompiled the code on the U9600 x86 laptop running Ubuntu with no
bother. The good thing about the laptop
was I could use the USB capture capability of Wireshark to have a look
at the stuff coming from Ozy (see 2 below).<br><br></div><div class="gmail_default" style="font-family:garamond,serif">The gateway will probably work on the Pi B1 with recompilation for the lower ARM core. The Pi B1 cpu is a bit underpowered but I seem to remember surprisingly low utilisation on the Pi2 when running 'top'. I believe the Pi's use a single USB port from the CPU, multiplexed to both Ethernet and USB ports, so ultimately it cannot be as good as dedicated USB and Ethernet ports on gateway hardware (maybe the BB Black?). However, on my Pi2 and a single HPSDR I tested PowerSDR at 384000, and also KISS, with both wide and normal displays; they were fine. I have not tested any other SDR apps to date.<br><br></div><div class="gmail_default" style="font-family:garamond,serif">As for outstanding issues: 1) I don't think the gateway will currently work with multiple Mercury boards in the same rig - I did not write it to account for more than one. 2) There is an occasional sync issue which appears, particularly after switching clients. I haven't been able to track it down and it seems that the USB is getting extra data in front of the 0x7f0x7f0x7f sync bytes from the Ozy. 3) The I2C control channel over USB seems to take up too much time - I have mitigated it in the implementation by reducing the frequency of I2C transactions, but its still a bit of a nag. The main source file 'listener.c' notes these things too.<br></div><div class="gmail_default" style="font-family:garamond,serif"><br></div><div class="gmail_default" style="font-family:garamond,serif"></div><div class="gmail_default" style="font-family:garamond,serif">The great thing about emulating the Metis is that it's much easier to fiddle around with the code than on a FPGA. It's a small source, so I'm confident it can adapted or enhanced to suit most needs without a major headache. I'm on another project now too, but ready to help if I can be of any assistance.<br></div><div class="gmail_default" style="font-family:garamond,serif">GL<br></div><div class="gmail_default" style="font-family:garamond,serif">Bob VK4YA<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 25 May 2015 at 01:51, Alfred Green <span dir="ltr"><<a href="mailto:nu8i@cox.net" target="_blank">nu8i@cox.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><span class="">
<div>On 5/23/2015 7:40 PM, Bob Wisdom wrote:<br>
</div>
<blockquote type="cite">Hi Alf,<br>
<div dir="ltr">
<div class="gmail_default" style="font-family:garamond,serif"><br>
I hope it's of use... I think BB Black should just be a
recompile with the correct ARM CPU options in the Makefile.
It might even be okay as is, since RPi2 uses a newer core than
RPi.<br>
<br>
The code for the Ozy-Metis gateway discovery responder might
be a bit too friendly for multiple HPSDR radios on the same
LAN in its unchanged form - I have only one radio.<br>
<br>
Currently, upon receipt of a discovery packet it will stop
transmission (if started), reply to the new initiator, setting
that new initiator as the client - and wait for a start
command. It should be pretty easy to change the code, and I
guess it *should* be changed, to become more compliant with
the Metis discovery spec.<br>
<br>
</div>
<br>
</div>
</blockquote></span>
Hello Bob,<br>
<br>
Tnx for the response. It turns out my RPi is one of the older B+
models rather than a -2. I have had a quick look through your code
and don't see any particular reason why it shouldn't work. Before I
spend much effort on this please let me know if there is a major
roadblock. Obviously it needs to be recompiled against the target,
but is there anything serious missing?<br>
I tried running it on a couple of my BBB units (latest models) and
while it appears to Make ok it has trouble with my libusb
installation. I will dig into that further.<br>
<br>
As for the discovery issue, that definitely needs to change. I can
envision a setup where we have multiple hpsdr-like units on a LAN,
and they should respond correctly. Currently, PowerSDR does not
handle the situation properly, but KISS and my homebrew derivatives
do a better job. As I see it, the client units, such as the RPi,
should respond either with 'I'm here' or 'I'm here, but busy'. Both
replies are covered by the Metis spec.<br>
<br>
I've also found out that my spare Atlas board is no longer working
for some reason, so I don't currently have a source to drive the USB
side of the translator. I could retrofit my
Metis/Mercury/Penny/Excalibur system with the Ozy card if necessary,
but I need to see what firmware versions I need to put on the
beasts.<br>
<br>
Anyway, thanks for putting this out there. As if I need another
project...<br>
<br>
73 Alf NU8I<br>
<br>
</div>
</blockquote></div><br></div>