Månedlige arkiver: august 2019

Disk speeds with the Raspberry Pi 4 Model B

Dingser, Diverse, IT, RaspberryPi

Background

The Raspberry Pi Foundation released the Raspberry Pi 4 Model B (I’ll call it RPi4 in this article) in June 2019, and a lot has already been said about the new features. The dual Mini HDMI ports and a selectable memory size (1, 2 or 4 GB ram) are the most obvious differences from the previous models, but the RPi4 also has a true gigabit ethernet port and two USB 3.0 ports. This makes the RPi4 a better candidate for a small NAS, as data transfers will be much faster than with the previous models.

I have testet a few different drive options for my RPis in the last couple of years, so I have collection of different drive types and adapters. This is mostly as I am skeptical to running what I consider «critical» systems from an SD card, and to see if there was any performance improvements to move from SD cards to different USB solutions. And so I started booting them from USB thumbdrives, bought a couple of USB-to-mSata HATs before I now have two USB-to-M.2 cases and one USB-to-NVMe case. And with this variety of USB equipment, I decided to see what kind of drive speeds I can expect with the new RPi4 hardware.

The equipment

SD cardSandisk Ultra 16 GB, Class 10, HC 1  
USB Thumb drive #1Sandisk Ultra Fit 64 GB, USB 3.0
USB Thumb drive #2Samsung Flash Drive FIT 64 GB, USB 3.0
mSATA SSDKingston 240 GB mSATA SSD + SupTronics X850 v1.3 mSATA HAT
M.2 SSD driveKingston UV500 120GB M.2 SSD + ICY Box IB-1815WP-C31 (USB-to-mSata case)
NVMe drive120 GB (Probably a Samsung EVO something) + Noname USB-to-NVMe case

So how was the tests performed?

I started out the tests with an RPi4 with a freshly installed and updated Raspbian Buster Lite 2019-07-10. Since RPi4 can’t boot from anything else than SD cards as the time of this writing, the RPi4 was booted this way, and the USB drives were connected one after the other, so no more than one USB connected drive was attached at any given time.

The command I ran was

hdparm -t <device> <device> <device> <device> <device> <device> <device> <device> <device> <device> 
example:
hdparm -t /dev/sda /dev/sda /dev/sda /dev/sda /dev/sda /dev/sda /dev/sda /dev/sda /dev/sda /dev/sda

By repeating the <device> 10 times on the command line, I get 10 consecutive read tests without any pause in between them. With 10 tests I can check for variations, and then calculate the average. I even repeated the series of 10 tests 3-4 times to see if I got varying results between the series, but the results were very stable. Even the strange M.2 results were stable.

For some reason, I couldn’t get the mSata HAT from SupTronic to work with the RPi4, so I haven’t been able to test this solution. I’ll dig out the other mSata HAT from the pile of equipment at a later date to see if I get that one to work.

OK, enough talk, let’s see some numbers

Here are the results so far:

As you can see, and probably already knew, there is a big performance difference between SD cards and the other disk types.

  • The SD card actually performed better than I had anticipated. I don’t know if the RPi4 has a faster SD card reader than the previous RPis – I might have to test this some time.
  • The two USB Thumb drives are approximately 4 and 3 times faster than the SD card, and their performance is quite stable.
  • As mentioned, I couldn’t get the mSata HAT to work, so I have to add the results for this drive later.
  • The M.2 SSD surprised me, as the results varied a lot. The best result was more than twice as fast as the slowest one. I ran the test several times, and there was always one of the ten runs that was much slower than the others. To exclude the possibility of equipment errors, I found my other, identical M.2 SSD drive and identical Icy Box case, but the same thing happened with this as well. So I have no idea why the results vary so much within a series of 10 tests run
  • The NVMe drive was by far the fastest one, and this is no surprise. The technology IS faster, so as long as the USB bus isn’t maxed out earlier in the test, the NVMe should really shine compared to the other drives. And it did.

I’ll have to dig up some more tests (write tests) to further check the performances of the different drives, but based on the hdparm tests I know what media I would prefer if maximum performance is a must.

Reading information from your AMS power meter #02: Attaching the USB-to-MBUS adapter to the AMS smart meter

Diverse, IT, RaspberryPi, SmartHouse

In the first post in this series, I explained how to get startet and connect your USB-to-MBUS adapter to the Raspberry Pi. In this post, I will explain how to connect the USB-to-MBUS adapter to your AMS smart meter, so you can receive data from the meter.

As mentioned in the first post, the standard HAN port interface (in Norway!) is an RJ45 connector. To connect your USB-to-MBUS adapter to the AMS smart meter HAN port, all you need is a sacrificial ethernet cable of suitable length. It does not have to be more than a Cat 5 cable, using a Cat 5e or higher cable will not add anything but cost.

When you have your ethernet cable, cut off one of the plugs as close to the plug as possible so you don’t waste any cable and strip off 1-2 centimeters of the cable jacket, exposing the four twisted pairs inside the cable. Now check the end of the plug you cut off. The colors inside the plug should look like one of these two:

(picture from www.theengineeringprojects.com)

It doesn’t matter if your cable looks like the left or the right color combination – the important thing is to check which one of the two you have got. My cable has orange/white and orange in pin 1 and 2 respectively, so those are the two wires I will use in my setup.

Pin 1 and 2 (left to right on the plug) are the only ones used, so make a note of the colors of the wires in location 1 and 2 in your plug. These are the two wires you must keep, the remaining 6 can be cut off to avoid confusion.

Now you need to strip off approx. 5 millimeters of the coating on each of the two wires you will use, to expose the bare metal inside. Take care not to cut of any of the many thin strands within each wire, you need them all to make a good connection to the USB-to-MBUS adapter. When ready, insert the wires into the two connectors on the adapter, and tighten the screws to make a good, solid connection. It doesn’t matter which wire goes into which connector on the adapter – the M-Bus is non-polar so there is no traditional «plus» or «minus/ground» in the wires.

My connection looks like this in it’s demo version. I will make a more solid and professional looking connection when it goes into production:

Now you are ready to connect the ethernet cable to the HAN port on the AMS smart meter. It’s as simple as connecting any ethernet cable to any RJ45 socket. I suggest you power on your RPi and connect the adapter to the RPi first, and then connect the adapter to the HAN port on the AMS smart meter. There is no real reason for doing it in this sequence, it just seems like the right way for me to do things…

That’s it for the physical connection. If you did a good job with the ethernet cable, your AMS smart meter should be connected to the USB-to-MBUS adapter, which in turn is connected to the RPi.

In the next post we will start experimenting with code, to try to read information from the adapter.

Reading information from your AMS smart meter #01: Connecting a HAN-to-USB device to your Raspberry Pi

Diverse, IT, RaspberryPi, SmartHouse

About a year ago, we got one of those new AMS smart meters from Aidon (the Aidon 6525), with an integrated HAN (Home Area Network) port. This port enables me to read power usage stats from the power meter, with a high sample rate so I get close to real time stats. Previously I had to report the energy consumption usage every month, but now it is reported automagically almost in real time (we’re talking every few seconds). This is something I want to explore, to see what I can do with it. Until now I haven’t done anything to try to read values and create my own dashboard at home, but this is about to change.

So what is the HAN port? The HAN port is a simple M-BUS interface, and all Norwegian smart meters must have one HAN port in the physical shape of an RJ45 contact, where only pin 1 and 2 are used for the M-BUS protocol, the other 6 pins are unused. There are several different options for adapters to connect to the AMS smart meter.

Just before the summer vacation, I ordered the HAN port to be opened from my power supplier, and I also ordered a cheap USB-to-MBUS slave module from AliExpress:

While we were away on vacation the module arrived, so it’s time to get this project started. I’ll use a Raspberry Pi Model B 3+ (I’ll simply call it RPi from now on) as the «brain», and connect the module to the RPi. The progress will be slow, as I do not have too much spare time for this, but I want to see this finished as quickly as possible

The first thing to do is to do a fresh install of Raspbian on the RPi. As of this writing, the latest Raspbian version is Raspbian Buster (Raspbian 10). I expect that you know how to install Raspian and boot up the RPi, so I won’t cover this. If you are fresh to Raspberry Pis, you can findt the official documentation here: https://www.raspberrypi.org/documentation/

After installing Raspbian and booting up, remember to secure the installation according to best practices. You can find some good help here: https://raspberrytips.com/security-tips-raspberry-pi/.

So now you have booted your RPi, and it is reasonably secure. Before you try to connect the USB-to-MBUS adapter, let’s see what USB devices are already attached. Run the lsusb command:

$ lsusb
Bus 001 Device 004: ID 152d:0578 JMicron Technology Corp. / JMicron USA Technology Corp. JMS567 SATA 6Gb/s bridge
Bus 001 Device 005: ID 0424:7800 Standard Microsystems Corp.
Bus 001 Device 003: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub
Bus 001 Device 002: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

The first device is my mSata to USB bridge, as I am running my RPi from a mSata disk instead of a SD card. The rest of the devices are the standard RPi devices that are present on all RPis

Let’s attach the USB to MBUS adapter, and see if the RPi will recognise the adapter. Run the lsusb command again after attaching the adapter:

$ lsusb
 Bus 001 Device 004: ID 152d:0578 JMicron Technology Corp. / JMicron USA Technology Corp. JMS567 SATA 6Gb/s bridge
 Bus 001 Device 006: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
 Bus 001 Device 005: ID 0424:7800 Standard Microsystems Corp.
 Bus 001 Device 003: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub
 Bus 001 Device 002: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub
 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Hey presto! A new USB device has appeared on the list! The USB to MBUS adapter is detected as a «PL2303 Serial Port», which only means that the adapter contains a PL2303 chip to «translate» signals from serial to USB, so the RPi is detecting this as a PL2303. It can’t see what is «behind» the PL2303 interface. This is common for all devices that use a PL2303 chip, so nothing strange.

So how can I communicate with the USB-to-MBUS adapter? It must have some kind of device file that can be used. We can use the command dmesg to find this information:

$ dmesg
[45236.494952] usb 1-1.1.3: new full-speed USB device number 6 using dwc_otg
 [45236.627927] usb 1-1.1.3: New USB device found, idVendor=067b, idProduct=2303, bcdDevice= 3.00
 [45236.627935] usb 1-1.1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
 [45236.627939] usb 1-1.1.3: Product: USB-Serial Controller
 [45236.627943] usb 1-1.1.3: Manufacturer: Prolific Technology Inc.
 [45236.679684] usbcore: registered new interface driver usbserial_generic
 [45236.680958] usbserial: USB Serial support registered for generic
 [45236.684271] usbcore: registered new interface driver pl2303
 [45236.684447] usbserial: USB Serial support registered for pl2303
 [45236.684639] pl2303 1-1.1.3:1.0: pl2303 converter detected
 [45236.688644] usb 1-1.1.3: pl2303 converter now attached to ttyUSB0

From the dmesg output, we can see that the adapter was detected, and was attached to ttyUSB0. This means that the device can be reached as /dev/ttyUSB0. We need this when we get a little further down the track.

For now, we have a fresh Raspbian install, and a connected USB-to-MBUS adapter. That is it for this post – in the next posts I will connect the adapter to the AMS power meter and see if we can receive anything.