Gateway 2 software updates

I've started to port some of the old libraries written for AVR architecture to new STM32 for new gateway with compatibility in mind. My goal is to still use Arduino based nodes for senors, authentication or relays, just because it's easy to implement new features quickly.

One of my the first and probably most used is RS485 wired library that manages communication over one pair of twisted wires. USART STM32 libraries in ChibiOS are divided to Low Level Driver and API. There are two ready to use USART both of the suitable for different kind of messages. One DMA based somehow preferring fixed messages and second, similar to Arduino serial, with queues and it's based on interrupts. I started to play with both, but I found rather difficult to build logic on top these APIs without changing internals. And because of this, I started with provided serial interrupt driven driver and created new RS485 library for STM32F4 MCU.

Luckily for me, really :), the SMT32F4 has build in logic that fully support my old RS485 library functionality. STM32F4 support not only 9 bit Multi Processor Communication as AVR, but it also provide interrupt on address match. Luckily again, the address register uses 4 bits wide target address, same as my old library, and it verifies 4 least significant bits of incoming header to 4 bits of defined address. Just perfect match, except the STM32 cannot reply the broadcast packets. Which is in reality not a problem for master at all, since only master do send broadcast packets, and every node know master address (0).

But of course writing a new driver for a new architecture was not easy. Thankfully to ChibiOS, I've managed to do so. As side effect, I must say that AVR debugging really sucks, because there is simply none. And once you learn to add breakpoints, stop program at certain line, and see at least some variables and registers, you do not want to go back. But back to new driver, in addition to compatibility between Arduino and STM32, I have also implemented acknowledgment, a feature that was not finalized in old library. And the ACK functionality is automatically performed by LLD on both receiving and sending.

Such ACK functionality also require appropriate changes in AVR side. At first I created incoming and outgoing ACKs directly in sketch. It was functional, but somehow slow, and I was a bit worried about the sketch complexity. And I've decided to update the AVR library according to STM32, I've added driver state and after a few long evenings, I hope I finally manged to do so.

The final packet structure is same to existing one:

-------------~~~~~~~~~~~~~~~~~~~
* A * P * X * D0 ~ D63 * C0 ~ C1
-------------~~~~~~~~~~~~~~~~~~~

- Required part
~ Optional data and CRC

A Address - 4 bits from and 4 bits to address.
   0  is master.
   15 is broadcast to all.
   14 addresses left for nodes.

P Packet definition - 2 bits type and 6 bits length.  
  Types: CMD - Command - user defined general commands value 0 - 6
          DTA - Data - user data length D0 - D63 and CRC S0, S1
          ACK, NACK - flags for data, using signature of data packet
         
X XOR of A and P, for basic transfer safety.

D0 - D63 user data.    
                     
C0 ~ C1  CRC for user data or signature for ACK, NAK. 
Basically it allows two kinds of transfers. First is command mode with value 1 to 63. Command 0 is reserved for ACK functionality. These can be used for some simple repetitive messages and expect predefined action or response. I use, for example, command = 1 to request full node functionality descriptor, i.e. request for registration. When gateway receive valid sensor data from unknown node, it issue CMD 1 to that address to receive its full descriptor.

Second use, is data transfer with maximum length of 64 bytes. It is completely up to the user, what kind of data are transferred. Every data packed is secured by CRC16 and ACK functionality compare these CRC and in case of mismatch invalidates the packet.

On the end I'm happy that new OHS gateway is slowly adopting old functionalities and further improving them.

Gateway 2

I did not post too much updates recently, but I was quite busy with new version of gateway. I manage to draw and let fabricate new PCB with 32bit ARM chip as main controller. For the purpose of first design I have shrunk the PCB to 100x100mm, but I have managed to squeeze all component I wanted there. Good news is that I was able to stay on 2 layers, and avoid much more expensive 4 layer PCB. I made the board at pcbway with the cheapest 6/6 method and the quality stays similar to my free boards. I will stay with them for sure.

After realizing that 100x100mm PCB includes all I need, I will most probably stay with this new format. To sum up there is:

• STM32F407 with 1MB of flash and 128KB of usable free RAM, running at 168MHz.
• LAN8720A Ethernet PHY with 10/100Mbit.
• Two step power supply with 12V to 4V switching and 4V to 3V3 LDO.
• Battery for RTC CR2032. STM32F407 has on-board RTC.
• 10 analog (balanced) inputs for PIR, smoke, ...
• 2G SIM800C module
• Radio for RFM69 or RFM95.
• 64KB SPI FRAM, bit expensive, but no wait times and blazing speed compared to I2C EEPROM.
• RS485 for wired connections.
• 2 relays for sirens.
• 1 tamper zone for enclosure. 
• Micro USB port for firmware update and direct console access.
• ST-LINK V2 port.
• 3 LEDs.

I guess it will pretty decent update to existing ATMega1284P.

I've made some mistakes during design of the PCB, also I forgot to wire some signals, or got them wired wrong. But, at least, I've managed to get the whole thing running with few cuts of traces here, or jumper wires there. Only hardware part, that I did yet tried, is wireless. After I manage at least initiate, send and receive some test packet I will go for new PCB revision with all corrections and the hardware part may be then ready.

I have already new sketch with addition to mount other then on-board 2G SIM800C. Basically there will be option to have SIM800C mounted, or there will be 2x5P connector to connect other modems like SIM7600 4G modems.

Remote uplodad and debug

Maybe you have similar setup at home as me. That is you have your OHS gateway close in some storage room along with your home server. I have it, my network panel, my small backup/sharing server (running excellent Open Media Vault), and my OHS gateway sit close to each other. And my desk computer is down one floor. It is rather inconvenient to push upgrades to gateway, one would have to put the code into laptop, go upstairs, take a chair and plug the FTDI programmer in. Each time you make some changes in code. So I have searched and found rather nice solution to this.

I use remote serial over TCP network. My server runs basically a Debian fork and after small search and couple of tries I found a program called socat. Socat can take physical /dev/tty* device and stream it over TCP. My example:

socat tcp-l:1234,reuseaddr,fork file:/dev/ttyUSB0,nonblock,raw,echo=0,waitlock=/var/run/tty,b115200

This above creates a stream of /dev/ttyUSB0 to TCP port 1234.

On the other side there is not much to install or setup, just use avrdude command line. Only thing you need to do in Arduino IDE is to select Sketch->Export compiled binary, this will place two hex files in you sketch folder. Then using avrdude command push the hex to created network serial port like this:

avrdude -p m1284p -c arduino -P net:10.10.10.127:1234 -Uflash:w:main_board.ino.with_bootloader.standard.hex 

Where net:10.10.10.127:1234 is target machine virtual network serial port, and other parameters represents Atmega1284p configuration with Arduino bootloader. Only one warning is issued by avrdue:

ioctl("TIOCMGET"): Inappropriate ioctl for device 

But it can be safely ignored. And this is it. Happy programming!

Updates in 1.7.6.4

This update is rather small and concentrates only on users having problems with false alarm of AC disruption on PSC-35A switching power supply.


If your PSC-35A or PSC-60A is repeatedly reporting AC On and Off alarms in OHS Log, then you should definitely go for the update. It adds kind of oversampling of AC_OFF pin, and also introduces 60 seconds delay when On/Off alert is issued.

As it is only minor version update configuration of you GW will remain as is.

Purpose of it, is to overcome the short, but frequent pulses of logical 1 to AC_OFF signal even when it supposed to be 0. This is caused by some logic inside the PSU.

If you still experience any issues with this PSU, let me know, best to use forum.

Firmware is pre-compiled in firmware section. 

Preparation for new OHS gateway.

There is almost all functionality in OHS gateway that I have wanted when I started, however I have internal need to carry on :). One thing, I would like to improve, is the crypto capabilities that can never be achieved on otherwise very nice ATmega1284P 8 bit MCU. It somehow led me to look further into another step that would be 16 or 32 bit MCU. There are many choices in therms of available MCUs and platforms. Maybe to stay on Arduino platform and choose some of the ARM Cortex available. But I have decided to stay with older brother of now used NilRTOS called ChibiOS/RT, since the "operating system" RTOS is maybe the most important for me.

ChibiOS can support variety of MCU including RaspberryPi and ATmega, but vast majority of supported MCU are STM32 families of many kinds. Looking at those mighty 32-bit ARM MCU, I have picked one called SMT32F407. These are high-performance Cortex-M4 32-bit RISC operating at a frequency of up to 168 MHz. They features a floating point unit (FPU), Ethernet, USB, RTC and so on. They have up to 1MB of flash storage and 128k of user usable RAM, and they are available in in various packages with varying pin count.

My goal is to create new gateway with similar functions as the current ATmega one, and then build up on this.The gateway may have different number of hardware zones, but I want to use wire and wireless nodes and zones. That is, I intend to still use Arduino based nodes s much as possible, just because of their easy to use nature. I plan to add GSM module on gateway, maybe as add-on board, so it can be swapped to 4G module in future. And also wireless radio, maybe as add-on board too. SMT32F407 has software defined TCP/IP stack, and it can be used with IPv6, Web Socket, SSL/TLS and so on. And what I like most, as ChibiOS supports many more even higher performance MCU, the future grow will be then much easier.

Saying all that I will continue to support, and develop new functionality on current ATmega gateway, as I use it at home :). The new one will not come anytime soon (this year), as it bring great deal of challenges in terms of HW and SW. Also I will keep the project open, as I do not like equipment that dies when its producer decides to cut it off, or just disable the required host server.

New PCB

It is always nice when someone appreciate your work, especially if you give the product to public as free to use. It happened to me as well, I was asked to review a PCB fabrication house called pcbway.com. Without too much hesitation I have sent them Gerber files of OHS gateway, and two of weeks later postman brought me the package, nice :).

I must say I have tried around 4 different China fabrication houses, and this one is fifth. I tend to do my board easy to hand solder, and I do not use fine traces or gaps bellow 10mils. This give me better trust to choose rather inexpensive manufacturing processes. There is not too much difference between ordering in pcbway and other houses, you do all as usual on their web pages. One difference though, is they probably inspect the gerbers by person. It came to me as I have used 6mil trace/gap option as the basic available, and within 1 day after submitting gerbers they proposed me to change it to 5mil. First time I've seen that actually someone had a glimpse of my layout before manufacturing. Of course it was a little more expensive, but still within the free coupon I was given for review.

The boards themselves are nicely made. I can compare to 2 other PCB houses I have boards from. I will skip the traces evaluation since I have no visual or other tool to do any reasonable comparison. But first think you notice with bare eye is silk screen, it is noticeably vivid and precise. It's placement is usually the weakest point in China PCB houses. But this board is done accurately, not faint and not smeared. I think using this fab one can afford to put logo on silk screen and not be afraid that it will come out ugly.
Second difference is via placement. When you use IC with many legs you usually route signals to other IC close to each other, this leads to having vias sit to each other in some pattern too. On such patterned vias you can easily spot the sharpness and bit placement. I must say there the vias on the PCB are great I would not be afraid to go with lower then my 0.3 millimeter.  Along with via quality goes actual hole placement. And it is similar to vias, nicely placed in exact center of pad.
Third difference I've noticed is solder mask, using loupe the mask is somehow more corresponding to what is draw in gerbers. Put it simply, exposed copper pads are smaller and more precise. This will help especially during soldering, the small components will not wander around, and IC will not have as many solder bridges.

Here is picture hopefully supporting my point, with pcbway PCB closer on top overlapping seeedstudio PCB. You can see here of-centered holes and wider solder mask along with nice silk text.

As I said on beginning, I do not develop over-complicated PCBs with many layers, buried vias or impedance control, so my evaluation is as erudite as hobbyist can offer. But I would say I will use the pcbway services in future for sure.