Category Archives: Computing

Computing, DIY, Green

Going Lopy

Leave a comment

Darren, g0hww has attempted to persuade me several times over the last year or two that I really needed to try some of the devices from Pycom.

I resisted for quite a while, but finally broke a few weeks ago. I was looking out at our Polytunnel while it was raining and was wondering what the temperature was in the tunnel. Sure, I could walk out in the rain and check on the thermometer, but that would require effort, and the potential to get wet etc.

So I caved, and ordered some Lopy4’s and accessories including a Pysense 2.0X.

Darren gave me a copy of his code for his own project, and after some bodging (principally around getting the deep sleep to work correctly), I had enough done for an initial deployment.

Initial Deployment
Test deployment

I used my Powermonkey Extreme from powertraveller.com to power it up and left it run over night. On checking it the following morning, I was slightly surprised and disappointed at how quickly the Powermonkey battery seemed to drop given the LoPy4 shouldn’t be using all that much power from the power bank(33.3WH), however the low temperatures are probably a major factor in this. The power consumption is approximately 0.95 of an hour at 13mA and 0.05 of an hour at 130mA, which comes to about 20mAh or about 0.1Wh at 5 Volts.

After looking around my ‘stores’ I found some other bits to make the deployment it a bit more practical. A recycled 12v PV panel and Victron Bluesolar PWM Light Charge Controller (thanks @floatsam for both of those), a recycled 7Ah SLA from a decommissioned UPS in work, and a DC/DC converter.

Phase 2
PV Panel ,Charge controller, and SLA added.
Phase 2 close-up
A closer look.

It worked very well at this location, but now it was in danger of getting watered along with some seedlings, so it had to move. A few screws, a bit of board and some Galvoband, and he-presto a new shelf.

Final location
LoPy4 in its current position.

The LoPy itself is close enough to the house that WiFi is working fine, no need for LoRa. So I spun up a Virtual Machine on my Proxmox server, installed a Mosquitto MQTT Broker, bodged some more Python, threw in a bit of influxdb, grafana and pushover. And now, as well as having some nice graphs, I’ll get an alert if the temperature goes to high or too low.

Screenshot from 2021-04-04 16-48-12

Success!

Amateur Radio, Computing, General, Green

Shack 2.0

Leave a comment

So, several months later, house move complete and it is time to get a shack operational again.

I am a fan of keeping things running when the power goes out. From a Amateur Radio Communications perspective, I have had a 80Ah battery in the shack for over 10 years and I have been using a West Mountain Radio Super PWRgate PG40S and Rigrunner 4010S to power my radio equipment and to keep the battery charged. My current ‘desktop’ is based on a Intel NUC 7i7BNH these along with their LCD’s are running off an older APC Smart UPS 1500, which gives between one and two hours of run-time should the power go out.

While everything was in boxes, I purchased a West Mountain Radio EPIC PWRgate (I wonder what adjective will be used to describe the 4th Generation!) this device can charge Lead Acid, AGM/GEL and LiFePO4 Lithium battery types, and, what attracted me to it is that it has a built in Photovoltaic (PV) Charge Controller. Which removes the need for a dedicated Charge Controller.

Sometime during the move, the old AGM battery died (Ophelia was its final ‘performance’). New shack, new battery, a Trojan EverExceed ST-1280 was ordered from O’Connell Batteries in Cork and duly arrived.

Plug-and-play? well not-exactly. After looking at the specs, the default ‘AGM’ setting in the Epic PWRgate needed some adjusting to avoid overcharging the battery. The battery specifications say 2.35 Volts per cell (for 12 hours), so the ‘Max charge voltage’ needed to be dropped from 14.4 to 14.1 volts, and the PSU set to 14.2. On Linux, the Epic PWRgate appears as /dev/ttyACM0, guessing I used 115200, N81, no handshaking and its console immediately popped up.

Battery:  1-Disable, 2-Gel, 3-AGM, 4-LiFePo4, 5-Other:    <3>: 3                
Reset to default values (Y,N):   (Y,N) <Y>? n                                   
Max charge voltage in Volts:    <14.10>:                                        
Max charge current in Amps:    <10.00>:                                         
Min charge current in Amps:    <1.00>:                                          
Trickle current in Amps:    <0.25>:                                             
Recharge voltage in Volts:    <13.49>:                                          
Max charge (minutes):    <720>:                                                 
Retry after abort (minutes):    <240>:                                          
Min supply voltage for charging in Volts:    <14.15>:

Once out of setup mode, it spits out readings about once per second. This includes what the state of the chargers is, the power supply voltage (PS), Battery voltage and charging current (Bat), Solar Panel voltage (Sol), Number of minutes in this charging state (Min)

 Trickle   PS=14.22V Bat=13.61V,  0.05A  Sol= 0.04V   Min=962  PWM=337  adc=6                                                    
 Trickle   PS=14.22V Bat=13.61V,  0.05A  Sol= 0.04V   Min=962  PWM=338  adc=6                                                    
 Trickle   PS=14.22V Bat=13.61V,  0.05A  Sol= 0.04V   Min=962  PWM=339  adc=6                                                    
 Trickle   PS=14.20V Bat=13.62V,  0.05A  Sol= 0.08V   Min=962  PWM=339  adc=6

Hopefully the battery is as reliable and lasts as long as the last one!

Amateur Radio, APRS, Computing, Mapping

APRS activity in Ireland

Leave a comment

In a conversation  late last year (at the TAPR DCC)  I was asked what is the actual level of APRS activity in Ireland.  Thinking about the answer for a while, I realised that I really didn’t know, and that got me wondering how to go about visualising it.

I quickly came across  Leaflet.heat, a Leaflet plugin plugin for generating heatmaps, so I  bodged together some python to grab packets of moving stations from the APRS-IS backbone and put them into a format Leaflet.heat can read.  After gathering about 6000 data points, here is what it looks like:
2017_03_28-Screenshot

So, there you go, it is fairly conclusive that Cork city has the most ‘on-air’ APRS activity. This is followed by Waterford area, Galway area and then the main motorways.

Amateur Radio, Computing, Technology

Ham Radio… Now What?

Leave a comment

I was looking for something to watch/listen to while tidying up my inbox today after being away for three weeks or so.  We took in the ARRL/TAPR Digital communications conference while in Florida. As I enjoyed this years DCC so much,  i went looking for last years DCC banquet speech.  Ward Silver, N0AX, gave an excellent talk on the direction the hobby should take for it’s second century.  I particularly liked his comment about contesting and being “able to heard the world turn”. Thanks to Gary Pearce, KN4AQ for attending the DCC and working so hard to make the videos available (feed the pig!).

Amateur Radio, AX25, Computing

Waiting for Pi

Leave a comment

Boy it has been busy of late, not what I expected 2013 to be.  I’m way behind on a lot of things I had planned to get done this year, but who isn’t.

Today I got one item off the todo list. Back in September at the DCC, John Hansen, W2FS presented the TNC-Pi, a radio modem for the Raspberry Pi. John was kind enough to entertain my questions, and I purchased one from him. This morning, I dug out the kit, fired up the soldering iron and put it together, quite therapeutic I must say.

TNC-Pi

Looking forward now to getting a Pi, and getting it all going, assuming I’ve not messed up in the construction.

Happy Christmas!

Computing, General, Technology

Staying secure

Leave a comment

Taken from Schneier on Security:

  1. Hide in the network. Implement hidden services. Use Tor to anonymize yourself. Yes, the NSA targets Tor users, but it’s work for them. The less obvious you are, the safer you are.
  2. Encrypt your communications. Use TLS. Use IPsec. Again, while it’s true that the NSA targets encrypted connections — and it may have explicit exploits against these protocols — you’re much better protected than if you communicate in the clear.
  3. Assume that while your computer can be compromised, it would take work and risk on the part of the NSA — so it probably isn’t. If you have something really important, use an air gap. Since I started working with the Snowden documents, I bought a new computer that has never been connected to the Internet. If I want to transfer a file, I encrypt the file on the secure computer and walk it over to my Internet computer, using a USB stick. To decrypt something, I reverse the process. This might not be bulletproof, but it’s pretty good.
  4. Be suspicious of commercial encryption software, especially from large vendors. My guess is that most encryption products from large US companies have NSA-friendly back doors, and many foreign ones probably do as well. It’s prudent to assume that foreign products also have foreign-installed backdoors. Closed-source software is easier for the NSA to backdoor than open-source software. Systems relying on master secrets are vulnerable to the NSA, through either legal or more clandestine means.
  5. Try to use public-domain encryption that has to be compatible with other implementations. For example, it’s harder for the NSA to backdoor TLS than BitLocker, because any vendor’s TLS has to be compatible with every other vendor’s TLS, while BitLocker only has to be compatible with itself, giving the NSA a lot more freedom to make changes. And because BitLocker is proprietary, it’s far less likely those changes will be discovered. Prefer symmetric cryptography over public-key cryptography. Prefer conventional discrete-log-based systems over elliptic-curve systems; the latter have constants that the NSA influences when they can.

If you haven’t already read the full post, you should.

Computing, Technology

Mirabox Kernel update

Leave a comment

So the background is that I have a lovely little unit called a Mirabox but I need to update the kernel on it.   I spent a good bit of time looking at various forums and eventually managed to piece together enough information to get a 3.9 kernel to boot for me.

First, I installed a cross compiler, then I built a kernel, with default options, like so.


PATH="/home/build/smile/armv7-marvell-linux-gnueabi/bin:$PATH" make ARCH=arm CROSS_COMPILE=arm-marvell-linux-gnueabi- mvebu_defconfig

PATH="/home/build/smile/armv7-marvell-linux-gnueabi/bin:$PATH" make ARCH=arm CROSS_COMPILE=arm-marvell-linux-gnueabi- zImage

PATH="/home/build/smile/armv7-marvell-linux-gnueabi/bin:$PATH" make ARCH=arm CROSS_COMPILE=arm-marvell-linux-gnueabi- armada-370-mirabox.dtb

cp arch/arm/boot/zImage zImage-with-dtb

cat arch/arm/boot/dts/armada-370-mirabox.dtb >> zImage-with-dtb

./scripts/mkuboot.sh -A arm -O linux -T kernel -C none -a 0x00008000 -e 0x00008000 -n 'Linux-marvell' -d zImage-with-dtb uImage

This kernel booted, but could not find a root filesystem. After a spending a bit of time looking, I could not find a NAND driver, so I opted for a filesystem on MicroSD instead.

Next, I replaced the kernel configuration with the one in this post, and rebuilt it. While that was building, I followed the instructions in this post, to create the filesystem on a MicroSD card.

Finally, I dropped the uImage created above onto a tftp server, loaded it with

tftpboot 0x6400000 10.4.50.166:uImage
set bootargs 'console=ttyS0,115200 root=/dev/sdb2 rootwait'
bootm

and the result is a working system.

root@dreamplug-debian:~# cat /proc/version
Linux version 3.9.0 (root@ubuntu-smile-build) (gcc version 4.2.0 20070413 (prerelease) (CodeSourcery 2007q1-10. Marvell 2009q3-11 20090730)) #2 Fri May 3 15:27:05 IST 2013
root@dreamplug-debian:~#

A very satisfying way to finish up before a long weekend!

Amateur Radio, Computing, D-Star

Wardriving and D-STAR Digital Data

Leave a comment

I’m slowly working towards doing some experiments with mesh networking (OLSR) and Icom ID-1 D-star Radios in Digital Data mode.  I’ve been wondering what coverage I would (should) see from a vehicle, back to one of the locations where I have an ID-1 in a fixed location (thanks EI3JB/EI8JA).

I got back from a trip today, grabbed an ID-1, an Omni Antenna, Laptop, a short bash script I wrote to ping and record replies along with a GPS position, and an old GPS-18 puck.   All the nodes have fixed IP addresses so the script is quite simple, ping host A, if A replies within 2 seconds, record the next position output from the GPS, try the same with host B, loop forever, nothing fancy or terribly accurate.

As I only have two nodes set-up, and without much preparation (shutting down chatty applications), I persuaded SWMBO to do a short (war)drive, while I kept an eye on the laptop.

This first picture below shows (the red dots) the coverage from Nicky, EI3JB’s place (roughly at the 8 in the R708 closest to the top). Note the few packets recorded in Tramore, shortly after I left my own place.

The second is obviously from my place, as it is much more centred on Tramore.

Nothing really ground-breaking in either picture, but useful to help visualise potential coverage nonetheless. There is a huge black-spot on the section of road just leaving Tramore, as far as Ballykinsella (L4061 on the map).  This is of no surprise, as it is a tough location  for 430Mhz signals to get out of. What was surprising though is the packets received from EI3JBs location out in Tramore.

Next steps are to get EI8JA up and running, and complete a more thorough survey.

Now though, it is time for a beer!