Site icon Robin Mulloy (gizmobin) on the web

RaspberryPI + Huawei 3G Stick = Router

Robin Mulloy

I have been working on some License Plate Recognition (LPR) technology for our OPS-COM software.  Everything has been going great except for some network setup and configuration challenges in a remote environment.  I should offer a bit of background on how all of this works, and from that, you can see the issue that this post describes.

Background Details

LPR technology uses a camera to send images to a processor.  Sometimes the processing happens within the camera and the resulting data set it pushed to a high level processor or data recorder.  With the setup I am working on, the camera is pushing data to an IP address that is described within the cameras configuration.  In the case of a static (mounted) camera, this setup works well since the camera is generally part of the organizations network setup.  What makes this straightforward is that the camera always has network access, and the data that is sent can pretty much be guaranteed to be delivered to the waiting processor/data logger.

Where things get a bit messy is when the camera is mounted on a vehicle and we want to do some of the data processing without the need to push data to some server back at the organization.  The setup I am working on is basically useful for remote vehicle enforcement.  In this case we don’t want to send data to a secondary processor if the vehicle is allowed to be on location.  So as an example, 5 cars are to be checked for validity.  The mobile LPR system drives past each vehicle, takes an image, processes the image and notifies the enforcement officer if the vehicle is not supposed to be parked in the given location.  If one or more of the vehicles are not allowed at the location we want to record a picture of the vehicle and its plate to substantiate the violation claim.  All of this should be able to happen in a true remote setting without a data connection.

Using a camera that processes the data helps since it serves a dual purpose to translate the images into textual information which can then be sent to the data logger or vehicle validation system.  Good “parker” or not, we may still want to record the imagery for future validation or tracking.  In our case with OPS-COM we are using Android devices to validate vehicle plates.  This remote setup fits well with the current implementation since the devices themselves maintain vehicle details which can be queried in the field, and again require no consistent data connection by using a remote database on the units.

So now we have a camera that needs to send data somewhere, and we have an Android device which works well to process the data.  We need something in the middle to manage their data connections.  The camera should be able to connect to a central system, and the Android device should also be able to connect to that same central system.  Then with this setup the camera can send data to a listening port on the Android device and the transfer does not incur any additional transfer fees.

The Problem

The problem now becomes the fact that the camera can only send to one IP address that is part of its static configuration.  This can be configured, but requires advanced knowledge to achieve and can’t be easily administered in the field.  A simple solution would be to make the Android device always accessible at a given IP address based on its MAC address.  Using DHCP on a remote router it is possible to make sure that the Android device can easily connect (and that the camera can as well) to obtain the same IP each time.  This unfortunately is not an ideal setup since the Android device may need to be swapped out for another or the router may need further configuration; definitely not a client friendly setup.

In testing I used a TP-Link router (TL-MR3020) which offered basic routing services plus 3G/4G access, but this setup was limited since it again required a high level of knowledge and access to the router device to configure things like DHCP and client address mappings.

So then I got thinking about leveraging a RaspberryPI as a programmable router, and what might be involved in also offering in the field 3G/4G access to allow for data syncing on the handheld devices.  Utilizing a RaspberryPI it would be minimal effort to create a web interface or RESTful API and offer basic configuration as an Android Activity.  The end product could be an intelligent router that could be easily configured.   With a true remote solution, the WAN access is not required but definitely adds something in regard to scalability.

Getting Things Setup

Enter the Huawei 3G Stick which I picked up at my local Telus store.  I have my cell phone on Telus, so swapping the SIM card would allow me to test the things without having to commit to a new data plan.   I also understand that these Huawei sticks work with a large majority of the cellular providers so this was an ideal choice.

I already had a couple of old RaspberryPI boards kicking around.  They were the old Model B, but would be sufficient for what I was trying to do (or prove ;).  So I pulled one of the boards out, dusted it off and did a full update and upgrade.

sudo apt-get update
sudo apt-get dist-upgrade

After this I installed the usb_modeswitch software which is used to switch the mode of the Huawei device from USB storage to MODEM.  By default without this software it comes up as a storage device (the device can also accommodate an SD card).

sudo apt-get install usb_modeswitch

When I executed the lsusb command I saw that the Huawei device (E8372h) was recognized at address 12d1:1f01  With usb_modeswitch installed, I rebooted the RaspberryPI and the Huawei device could then be seen at 12d1:14db  which based on my research was the Ethernet module on the device.

A quick check on the interface configuration (ifconfig) listed a new device eth1

I added the following lines to /etc/network/interfaces and rebooted again.  These commands should bring the new interface up and allocate an IP using a DHCP query against the Huawei… what can’t this thing do!

iface eth1 inet dhcp
allow-hotplug eth1

Once the device rebooted, I could see using ifconfig that there was a network now at 192.168.8.x with the device assigning my RaspberryPI the IP 192.168.1.100  Opening a browser and navigating to the Huawei configuration page at 192.168.8.1 I was able to see that the 3G network was also online (also indicated with a solid blue light on the device).

Disconnecting my wired network, I tried to use it as the gateway to the outside world and that did not work.  Issuing the command route I was able to see that with my hard wire network removed, there now was no default route for traffic.

Issuing the following created a default route and resolved the issue..

sudo route add default gw 192.168.8.1 eth1

Note: I haven’t tested a reboot on the device at this time with the wired LAN disconnected.  I suspect I may need to add the gateway to the boot config, but would not be surprised if the RaspberryPI figures it out on its own.

Next Steps

So with the device running and offering internet access I next needed to see about allowing devices to connect to the RaspberryPI.  Interestingly, the Huawei devices among other things can also act as a WIFI hotspot (keep in mind this thing is about the size of my thumb!  ;).  Opening a laptop and scanning my network, I was able to see the Huawei WIFI network, and using with the details written on the device label attached on the back of the unit, I was able to connect.

With this done, my remote laptop now had access to the Huawei and the 3G network behind it.  The laptop was assigned the next available IP (192.168.8.101) by the Huawei DHCP server and as a result I was able to ping my RaspberryPI with no issue.

So just a quick run down on what’s to come based on findings…

Hmm… this should work quite nicely, and will offer a clean easily managed solution!  🙂

In Conclusion

The Huawei E8372h device appears to offer everything I need to turn a RaspberryPI into a workable solution.  Originally I was looking to use the RaspberryPI as a router + proxy, but based on the functionality that is exposed by the Huawei that will not be entirely necessary.  Instead, now I am able to focus on developing just an intelligent proxy to allow the LPR camera and Android devices to easily communicate through the network.  If equipped with a SIM card this setup could also offer WAN access.

I’m not sure what the software implementation will look like in the end, but this has the potential to make the (software) setup easily configurable in the field.  And the best part…  this entire setup will run off any USB power source which is perfect for a mobile solution — technology never ceases to amaze me!

Further to this… now I have a true (tiny!) mobile hot spot that with a quick swap of a SIM card can offer the family Internet access anywhere.

Exit mobile version