OHS 2.0.4

Over past few months I have prepared new version of OHS gateway called simply 2.0.4. It is new iteration of my 2.0 version fixing layout defects and integrating new features. Here are the specifications:

• STM32F407 with 1GB of flash and 128KB + 64KB CCM of RAM, running at 168MHz.
• LAN8720A Ethernet PHY with 10/100Mbit.
• Two step power supply with 12V to 3V8 switching and 3V8 to 3V3 LDO.
• Battery for RTC CR2032. STM32F407 has on-board RTC.
• 10 analog (balanced) inputs for PIR, smoke, ...
• 4G SIM7600x module
• Radio module for RFM69HCW, or alternatively RFM95.
• 128KB SPI FRAM.
• RS485 for wired connections.
• 2 relays for sirens.
• 1 tamper zone for enclosure. 
• Micro USB port.
• ST-LINK V2 port.
• 3 LEDs.

The main changes are GSM part, which now sports 4G/LTE modem from SIMCOM SIM7600x, and SPI FRAM with double capacity.

SIM7600x is decision that I've been thinking about for some time. On one hand the module is quite expensive compared to 2G modules, but on the other the 2G is becoming phase out in many countries. It is quite a dilemma, but I decided to invest into module that will have long life expectancy. There are always more difficulties. One is that the hardware needs to be able to speak with 1V8 logic presented on module, which I have solved by adding MOSFET level shifters. And second, that the module is bigger, and I neede to place it on the back of PCB. I have also removed the mini SIM holder, and replaced it with smaller and more up to date micro SIM.

There are several versions of SIM7600 module. One global, most expensive, that is supposed to work in all regions. And the regional ones for Europe, North America, South America, Asia and so on.

FRAM size has doubled for the reason to store some larger data needed conveniently.  First half (64KB) is used as before to keep 4096 log entries for gateway logger. Second half will be available to several new functionalities I plan to add to gateway software. I was also tmepted to add a uSD card, but it is easier to store data on synchronous SPI FRAM, then to access uSD with file system that can be damaged or not present. Not to speak about wiring.

Other changes not so visible are RC circuits on battery and power signals of UPC. These are nicely filtering out the spikes that are sent to gateway, eliminating the need for software compensations. Without them the gateway has wrongly reported AC power OFF signal.
Also there is now a shotky diode, to add polarity protection to RTC battery.

OHS logo

I'm having fun with the new http server. Since it serves static pages quite well I have created new logo for OHS and even derived favicon out of it. It will part of login screen, and 404 page. There is still plenty of storage on MCU flash (my STM32F407 has 1MB).

I have also polished a bit of JavaScript and it will hopefully bring a bit of comfort to user interface. Namely there is enhanced enable and disable script, that can toggle various buttons, selects and such html elements on and off. Second is a simple password verification script that can verify password text in two password inputs, before it is sent to httpd.

The scripts work with element ID, and since all OHS http elements are rendered with ID, all you need to do is add:

onclick="en()" and
onclick="dis()"

to the master element. This master that triggers other elements property enabled or disabled by defining array of affected ids, such as:

var x=document.querySelectorAll(\"#xx\");
var y=document.querySelectorAll(\"#a1,#a0\");

Where x is array of disabled when true, and y is array of disabled when false.

Moving forward with OHS2

Just to post latest update about my software progress on OHS version 2. I must say I'm quite happy that I have base functional system with many main system components running on my development board. Namely:

1. RS485 with new library for Arduino. Sending command and messages with ACKs. All the bits travel back and forth nicely and all timing look good on logic analyzer.
2. GSM module work well wit accompanied new library for SMT32.
3. Logging to FRAM.
4. Relays are fine.
5. Battery backup storage in SRAM is fine along with ruties.
6. RTC, although there is now only UTC.
7. HTTPD is working with static and dynamic html pages and and also POST is functional. Web server now includes pages for system info, zones, groups, nodes, users, keys and log.

With all this I can already use authentication, zone monitoring, groups, and data log.

If someone is interested all the source is in GitHub, and also any contribution is welcome.

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.