[hpsdr] Problems building ghpsdr receiver client (from ghpsdr3 project) on Mac OSX

Jeremy McDermond mcdermj at xenotropic.com
Mon Jan 9 16:16:41 PST 2012


On Jan 9, 2012, at 10:53 AM, Mark Leone wrote:

>> It certainly wasn't envisioned as something we were supporting the
>> rudimentary Metis IP stack was written.  John's been looking at writing
>> a Metis firmware such that it's a bit smarter, but I haven't seem how
>> his struggles are going with that.
>> 
> Thanks for the explanation. I see now why any software talking to Metis will
> have to work in discovery mode, since it doesn't have full Layer 3
> capability. As far as pinging Metis from a remote subnet, I'm sure it was
> working. I powered my HPSDR down and back up again and saw the ping success
> packets stop and then start up again. This worked because I created static
> routes for each direction (e.g. route add -net 192.168.2.0 netmask
> 255.255.255.0 eth0 for routing to Metis) and I enabled IP forwarding by
> executing 'echo 1 > /proc/sys/net/ipv4/ip_forward'. In any case, routing is
> a moot issue, since I need to have layer two connectivity across the two
> interfaces in order to pass the discovery protocol in the broadcast frames.
> So I'll keep working on the bridge implementation. 

Upon thinking about it now that I'm a little more awake, I understand why it's working.  When Metis receives the start packet from heterodyne, it remembers the IP and MAC addresses of the sender.  The MAC address is of the Ubuntu box, but the IP address is going to be of your Mac.  When Metis fires back a packet, it's L2 address will get it to the Ubuntu box but the Ubuntu box will know that the IP address isn't one of its own.  So, since IP forwarding is on, it looks in the route table and pushes the packet to the Mac again.

I was having a hard time because, since Metis doesn't have any clue about a default route, I was trying to figure out how the packet was having a valid return path.  While the mechanism happens to work, it certainly isn't something we envisioned in the design.

>> Incidentally, I've tested Metis over my Airport Extreme with my MacBook
>> Pro on 802.11n and it works fine.  I haven't tried scaling back to
>> 802.11g, but I honestly don't think there will be a huge issue for
>> single hardware/firmware receiver applications.  The data rate is well
>> less than 10Mbit/sec in that case.
>> 
> That's good to hear. I have an older 802.11g router, with a moderately
> strong signal at the Ubuntu system, so it will be good to get a data point
> on how well that works.

It works well enough in my testing that I've had envisioned an iPad application.  This would be something different than John's work in that it wouldn't require any computer to do pre-processing on the data, but would be able to handle direct decoding of stuff from Metis.  I'm not yet sure if there's enough processing power to make it work, but I do intend to find out when I get some hardware.

> 73
> 
> Mark - K4XML

--
Jeremy McDermond (NH6Z)
Xenotropic Systems
mcdermj at xenotropic.com



 1326154601.0


More information about the Hpsdr mailing list