just to let you know that you can easily install and run the free IBM Informix Developer Edition (IBM's IoT database for the edge) Docker image on the netPi. The docker image can be found here:
As soon as the image is up and running, you will have access to a simple sensor database which can store JSON formatted sensor readings in a time series. The Informix database can be accessed through a REST API, MQTT, the MongoDB API, JDBC, ODBC, .NET and more.
I will compile soon a short tutorial on how to use the Informix DB on the netPi. In the meantime you can also refer to a series of short How-To articles which I posted some time ago on the Raspberry Pi Forum: https://www.raspberrypi.org/forums/viewt...hp?t=97199
If you might have any questions, just let me know...
Hi
In my application the netPI is enclosed in a metal cabinet and the WiFi signal is very low.
Is it possbile to remove the antenna and have an extension cable? Which kind of connector is there?
Preconditions for an automated build are:
[ul]
[li]You need a Docker Hub account[/li]
[li]You need a Github account[/li]
[li]You need to create a repository on Docker Hub in automated mode[/li]
[/ul]
How to setup a Docker image repository to be built automated on Docker Hub servers can be read here.
Next to a Docker Hub account a Github account is needed to allow Docker Hub accessing your sources during the web build process.
A file named Dockerfile is basis for any built process whether it is built remotely on the web or locally using the Docker (CLI) Command Line Interface (if you have access to it).
This file contains the command instructions in adjacent order executed during the build process. There is just a set of maybe 10 commands the Dockerfile interpreter understands.
When creating a new repository on your Docker Hub registry you can specify whether or not it is of type automated under the tab create.
If you chose Create Automated Build you have to link your repo to the Github sources. After that you can immediately start the build process if the Github account contains the Dockerfile at least. When finished the built image will be placed on your repository ready for download.
As you can imagine Docker Hub servers are all x86 based platforms. Actually they can't generate ARM processor based code needed for a Raspberry compatible output. With the following trick described here you can extend your Dockerfile by a set of files moving Docker Hub to emulate an ARM CPU during build process. Precondition is that your automated build rely on base images provided by group resin.io containing the ARM software emulator QEMU.
Here is a code extract of how to prepare your Dockerfile for an automated web build:
FROM resin/... (can be any resin.io ARM base image)
ENV QEMU_EXECVE 1
COPY armv7hf-debian-qemu /usr/bin
RUN [ "cross-build-start" ]
... all your other commands
RUN [ "cross-build-end" ]
The script cross-build-start brings the build server into a state to use the QEMU ARM software emulator that is part of any resin.io base image on all next commands. The script cross-build-end at the end exits the emulation mode.
The script files you need can be obtained from here to copy them over to your github repository into the folder armv7hf-debian-qemu in the example above.
I am trying to transfer some data as done in ChannelDemo() found in PNS_simpleConfig.c on the hilschernetpi/netpi-netx-programming-examples and I think I found a discrepancy between the implementation/netX51 firmware and the GSDML file. As I understand the source code, the 10-byte input is echoed to a 4-byte output (from netPi view).
In TIA Portal the GSDML-file gives me a 10-byte input and a 4-byte output (from PLC view).
I think for one view it sould be the other way around. Just try to force all 10 netPi input bytes to a certain value while the PNS_simpleConfig ChannelDemo is running using the GSDML description included in the image.
Is there a netPi profinet firmware and GSDML-file which is capable of transferring more than 4-bytes?
I am experimenting with bluetooth low energy on the netPi. Unfortunately it is not possible to start a bluetoothd daemon inside a docker container beacuse it connects to the system dbus (The same dbus as on the docker host system) where a bluetoothd is already running. I am able to talk to the bluetoothd running on the host system when I share the dbus socket with the container but unfortunately the bluez package on the host system is outdated (5.41) and some features I need are missing. Is ist possible to install a newer/the newest bluez version?
netPI's pluggable advanced networking modules are called NPIX which stands for NetPI eXtension modules. The interface is like the HAT interface you know from Raspberry already but provides signals from the network controller SoC netX additionally (netX communication was not established yet in any of Hilscher NPIX designs).
A standard plastic 52 pin mPCIe socket provides the physical contact between netPI's motherboard and the plugin modules. The mPCIe socket was selected cause it is delivering the appropriate number of signals. It is not providing a real mPCIe signal bus! Due to its popularity you'll find socket and connector in any PCB board design software's library. The whole PCB has roughly a size of 4 cm x 4,5 cm and its board outline can be found as appendix to this topic.
netPI does not have a physical reset button. The official method to shutdown the device is clicking "shutdown" within "Control Panel" management tile under the tab "System". The shutdown will take about 10 seconds and is finished when netPI's heartbeat LED "ACT" goes on for a second first and finally remains off forever. Only in this state it is allowed to remove netPI from its power source. This ensures there are no more write accesses to the SD card media that could else easily damage the file system when interrupted during an active write.
On the other hand, a power loss or an intended/unintended remove from power source cannot be controlled and can happen at any time still. netPI's industrial grade SD card supports a mechanism called Data Clone System (DCS) to prevent data corruption during active writes. DCS holds the data to be written in a second clone buffer always. On every power cycle the card checks the last written target block's data against the buffer. If different it re-writes it and solves the problem. This mechanism vastly reduce the risk of a damaged file system.
This issue is affecting web sites to be opened in Firefox Browser (e.g. netPI's web GUI landing page) if self-signed certificates are used. It can be encountered when the certificate has been replaced multiple times by Firefox with new same certificates that all have identical Subject/Issuer information. This is the case if you restore your netPI to factory default and Firefox wants you to reaccept the untrusted certificate during the next browser session.
A way to correct this problem is to browse about:support in your Firefox address bar instead of an URL. Click then Open Folder under topic Profile Folder. Locate certx.db e.g. cert8.db in your file explorer and rename or delete it (e.g. “cert8.db.bak”). It may be necessary to have Firefox close to access the file.
Start your Firefox and visit netPI's landing page again and the problem is gone.
