'Mobile' operation without a network?
Has anyone devised a method of running the KiwiSDR connected directly to a computer without a network? Possibly with a crossover cable?
I would like to assemble a mobile/portable system for use in noise tracking, using a tablet, batteries and a small loop antenna. The main consideration I can think of is the IP address assignment, but there are probably others.
Ideas would be appreciated.
Thanks,
Neil
Comments
I think you will find a solution in this method. There are other ways, but this is probably the easiest.
Ron
KA7U
I haven't tried this myself in a long time. But our documentation has some instructions here: http://kiwisdr.com/quickstart/index.html#id-net-p2p
But there is also a note there that it doesn't work with Windows 10 anymore. Can anyone verify? Does anyone successfully do this currently?
When I connect the microUSB port of the the Kiwi to a USB port of a Raspberry Pi, the Pi sees a new ethernet interface appear on LAN 192.168.7.0/30. The Kiwi assigns itself 192.168.7.2, but I forget if it acts as a DHCP server to the Pi. So on the Pi you may need to assign that new USB 'dongle' the address 192.168.7.1.
After that the Kiwi UI can be accessed at 192.168.7.2
I've returned to examining operation using the USB port recently. I had the same experience Rob reported in that I was able to talk to the Kiwi's BB on 192.168.7.2/USB but this seems to be a complex system and I don't yet understand it.
The reason for doing this is two-fold. Most importantly, I'm trying to create a completely stand-alone and isolated Kiwi Receiver system using an LF-HF active probe antenna system I've created along with an isolated WiFi'd Az/El rotor. The entire system is to have relative small volume and have low self-capacity in order to preclude common mode ingress. Since the system becomes a 'counterpoise' I want to keep ithe impedance high and the currents low. Another reason for wanting a "power over USB" router is to avoid ground loops that are created within that isolated system when a router's power ground and LAN ground/reference are different. If knew how to achieve this with a USB-dongle I'd do it but I don't so I'm trying with the external router.
I've modified the BBG to add the 'missing' R168 which ties the USB host (type A) and client (micro USB) power connectors together. Doing so allows an external WiFi/LAN/USB router running OpenWRT. I'm presently using GL-MT300N-V2 which is very inexpensive, Open Source and seems capable. In addition to the jumper on the Kiwi's BBG I added a jumper within the router to allow it to connect to the Kiwi's power. I can now power the router via the Kiwi or the Kiwi via the router and not create additional current paths. Only a single USB host-client cable is required.
Having done this, I have successfully logged into the router on its WiFi 192.168.8.1 'control channel'. There I can either use a web interface or ssh into the (Linux) OS to configure OpenWRT. After acquiring remote router access I've configured its USB port, called a 'tethered' port in contrast to the LAN or WiFi interfaces, to be on 192.168.7.1. Just in case I also turned on DHCP for that subnet in case the BBG needed it.
I think the BBG did not need it, I think the 192.168.7.2 address is probably static, because I found myself able to connect through to the BBG using SSH and the Kiwi SN# as password. This gets me into the Kiwi entirely via WiFi and with no ohmic connections to the whole shebang.
It's at this point that I really need help. Having started with no other connections upon examining the BBG I find no evidence of the Kiwi image being loaded. Worse, after a few minutes the BBG turns itself off. If I start with no USB connection (powered via the Kiwi's +5) , the Kiwi does come up, grants itself a 169.254.6.x sort of address per the blue lights but will still talk to my router/kiwi SSH connection but it then again proceeds to turn itself off.
There seem to be a lot of layers of complexity here and I'm not proficient in any of them. I'm not learned WRT OpenWRT, I don't fully understand the BBG start-up networking and interface environment and I don't understand the process in which the Kiwi software takes over and the impact on networking and general operation.
Can someone point me to link(s) or other good reference for this territory or, better yet, has someone already passed this point and can adivse me as to how to proceed? It's clear that the hardware is capable of what I want but configuring it all is beyond my present capability. I need help!
"This is an old thread, but I thought I'd add a solution. I found that the BBB would reset part way through booting when powering the BBB via the barrel connector or Vdd_5v pins. I needed to add a large capacitor. 10,000 uf did the job. "
Not saying that is completely the answer but the voltage at boot bites hard if the source is not designed to sink enough instantaneous current, which I think could be the case here. Obviously that will slow the rise of the 5V so I'm not sure if the PMIC will take that. I've been pushing for good solid supply for ages (as specified in the instructions) but never though about a dirty big cap on the board and letting the PMIC handle the start.
In case it is not obvious I could not see much of an issue with the rest of it but not much point in checking networking if boot does no properly complete.
Stu
Stu,
Could be part of the issue I'm seeing. Others have mentioned this so I'll recheck power quality. It's possible that I've degraded it with the POUSB system. There's also been a report that reloading the entire OS of an apparently functional Kiwi (AI) can make a difference in this regard.
I'd still like to understand the power-up and interface allocation environment of the BB better.
I didn't realise it was the AI, that does have a higher current take anyway.
Would you not consider doing some test on a BBG first?
I didn't really get on that well with the wireless networking on the AI so from a personal failure standpoint I'd prefer to start network/supply tricks on the BBG which has lower current requirement and older generation (less "clever") networking. The networking should not be that challenging but the supply needs to be in if it is to make any sense.
Sorry, my post was confusing. I am in fact developing on a stock KiwiSDR with a BBG. I won't move to an AI until I sort this one out.
Supply is OK so that's not the issue. However I'm now investigating USB client/host signalling. The BBG has a connection from the microUSB ID line to the processor. I suspect that the router is not getting a "present" signal as it probably must. Maybe there's a BBG expert on here who can describe the internals of the process as documented in the BBG system reference manual before I slog through to try to figure it out.
OK, one final post on the subject. Here's a summary.
A stock KiwiSDR with only a client USB (micro USB connector) connection to an inexpensive router can be used to create a stand-alone WiFi'd Kiwi with power&Ground as well as USB data. thus avoiding both ground loops.
The results are very good. Even powered from a SMPS buck converter no data or switching spectral lines are visible across the entire range of the Kiwi,even with an antenna connected. Common mode noise, so prevalent seems to have been eliminated.
My problems in getting to this point were mainly cockpit related. I have a confusing system and I don't know what I'm doing.
Starting with the main computer which is Ubuntu Linux (ge-linux-desktop), LAN connected to a home gateway/router. I used an unused WiFi port to connect to the router over it's 'control' WiFi SSID set to the factory default of 192.168.8.1. That OpenWRT router is set for "Tethering" mode. I used its web interface to configure the USB port as 192.168.7.1/24 (eth1) and also SSH into it as root. Once there I added a routing entry to provide a default gateway back to the Ubuntu host. The routing table on that router shows:
Destination Gateway Genmask Flags Metric Ref Use Iface
default ge-linux-deskto 0.0.0.0 UG 0 0 0 br-lan
192.168.7.0 * 255.255.255.0 U 0 0 0 eth1
192.168.8.0 * 255.255.255.0 U 0 0 0 br-lan
I connected the 5V SMPS buck converter to the Kiwi's power input and because R168 on the BBG has been installed, that power is passed to both of the USB connectors on the BBG. Within the router I added a second jumper to feed DC 'backwards' from the routers USB-A to it's power-only-input USB-micro aconnector. Write me if you want HW details on either of these.
With a standard USB-micro/USB-A cable connected from the Kiwi/BBG to the WiFi router, the router is both powered and provided data. However the result is that after powering the kiwi/router on it's necessary to WAIT for the kiwi to not find a normal LAN network and self-assign it a 169.254.6.x address (I didn't time it but this took a couple of minutes or more), the four blue LEDs stop heartbeat and start reporting the (unused) 169... LAN address, but the USB-client port able to talk to 192.168.7.x over USB. At this point the Kiwi web server gets loaded and becomes operational. Success.
From the root session on the WiFi router I in turn SSHd into the Kiwi/BBG which has assigned its client-USB 192.168.7.2. (As far as I can tell this is always the address it assigns.) The Kiwi's routing table looks like:
Destination Gateway Genmask Flags Metric Ref Use Iface
default * 0.0.0.0 U 1002 0 0 eth0
link-local * 255.255.0.0 U 0 0 0 eth0
192.168.7.0 * 255.255.255.252 U 0 0 0 usb0
and after waiting for the Kiwi web server to come up I am able to finally access a normal Kiwi at 192.168.7.2:<port number>. The spectrum looks very clean, noise floors are all correct and when an antenna is connected everything works.
This routing configuration is probably not yet correct since the Kiwi doesn't have a path to the Internet, only to the router and the Ubuntu host. There's probably a better way to do all this but I haven't sorted that part out yet. Probably there needs to be an explicit default route to the router or something. But since the goal of all this was to get stand-alone, single USB cable connected KiWi operational I think both the hardware mods and the functionality is validated.
Probably this answers the inital question of simple stand alone operation to a connected computer. As long as both computer and Kiwi have power, if the computer's interface is set to be static on 192.168.7.1 or 192.168.7.3 I think it may be able to access the Kiwi the same way. Someone else can verify this.
Glenn n6gn