I didn't remove any packages after full-upgrade and simply rebooted with a backup in place. After restart, I removed all obsolete packages but those which had unipi or axon in name (see later).
Currently, I'm still using the kernel from Buster because the kernel packages in Bullseye appear to be broken. If I understand correctly, we should be able to use unipi-kernel-modules-dkms with the normal Debian kernel. Unfortunately, it currently has broken dependencies, namely the unavailable unipi-kernel-headers and unipi-os-configurator-data.
Here is the list of obsolete Buster packages I have left on hold:
@arolli Hello Antonio,
depends on what the project is. Neuron is cheaper and more suitable for smart home/home automation projects. Patron line is more expensive, but is built to full industrial standards. As for longevity I definitely recommend Patron, in case you decide to use Neuron longevity mainly depends on used SD card, check our eshop for SLC uSD cards, they help a lot.
In the current version of Mervis OS 220.127.116.11, writes to the card already occur at least, according to the set interval for storing retain variables.
For a similar reason, the history is newly stored in RAM (data is lost after the power is disconnected or restarted), which does not matter in combination with the cloud-based Mervis DB.
If you disable writes to the internal storage (SD card), there are two possibilities of what can happen (depending on how you disable the writes):
Mervis RT always unlocks the storage when writing retain variables, writes and locks the storage again for writing (basically the same behavior as now)
Storage will be permanently locked and retain variables will not be writable. Likewise, it will not be possible to upload a new assembly (program) from Mervis IDE.
In general, I recommend purchasing an SLC card with a longer lifespan and resistance to random power outages, etc., for the operation of the controller.
You can read more about this issue in this article.
@AVsetula Thanks for your reply. To help troubleshooting, I made up an RJ45 connector breakout and viewed the 'data out' pin on an oscilloscope. It soon became clear that the problem is one of intermittent connection. I connected the scope at the end of the device chain (socket 8 on the hub) and if I connect all the intermediate sensors, and tape their cables to the bench so there is no strain on the RJ45 connector, all is well. I can see nice sharp 0V to 5V data transitions on the scope.
But, any movement on the cables causes an intermittent loss of contact, immediately apparent from the 'illegal' voltages that appear on the scope display.
I have disassembled the hub and buzzed out all the solder joints: no problems. The issue seems to be either with the RJ45 plug/socket connection, or with the sensor cable/RJ45 plug crimp integrity.
It doesn't help that the insulation on the temperature sensor cables is extremely stiff, so that any movement of the cable puts strain on the RJ45 connector.
I think I will need to arrange for cable clamps to hold the sensor cables in place. The hub will be mounted in a plastic box, so this is feasible: I should be able to 3D-print something.
From your description, I assume it's a wrong connection. The digital inputs on our units are not potential-free, but instead respond to voltages in the range of 7 to 35 VDC. At the same time, it is necessary that the negative pole of the voltage source is connected to DIGND.
In this case, however, it may not be a faulty HW, but only an inappropriate output setting:
The digital outputs on the Unipi units also enable the so-called PWM mode, where the output is controlled in a different way than during normal on / off switching.
Another function that could affect the outputs in this way is the so-called DirectSwitch function.
If you work in Mervis SW, you can upload the default configuration simply by creating a new project in the Mervis IDE, assigning a PLC and uploading the Unipi module configuration.
For other SW solutions, I recommend checking the values in the Modbus registers.
To check that PWM is off, check registers 16 to 19, all of which should contain a value of 0.
To check that the DirectSwitch function is turned off, check register 1014, it should also contain the value 0.
as the first point, let me briefly describe the device architecture:
Every Neuron device consists of one, two or three coprocessor boards. In the device-tree overlay, the full three-boards configuration is always supposed.
During the driver-load phase (probe), the driver tries to contact all three boards (messages in the syslog come from this phase). In case of success, the driver creates the sysfs structure for every responding board (called io_groupX).
This routine is invoked at driver load only - ie. at the boot time.
To your questions:
There is no way how to check the presence of a non-coprocessor board. These boards are just simple I/Os without any "intelligence".
In case a co-processor board does not present at the boot time, no sysfs structure is created for this io_group.
This status is a link to the currently loaded device tree. As mentioned above, all three boards are still active there, so you always read the "okay" string.
In case the board is not found during the boot phase, no sysfs structure is created.
Maybe standard Linux SPI subsystem statistics can be useful for you, e.g.:
Unfortunately, so far we only have Neuron S103 with RPi4. This is due to higher cooling requirements and due to the different layout of connectors on RPi4.
The difference in communication speed between the variant in one box and the variant with Extension is not so important for most applications and it always depends on the optimization (number of read registers, reading period, etc.).
In general, you can assume that the speed for internal communication is 115200 bps (and higher) and the communication speed via RS485 is according to the settings, but 19200 bps is used by default due to the excellent ratio between speed and stability.
Just for the record, we successfully menderized neuron-opensource-os_image-20210806.0 and the PLC now boots up. There seems to be an issue with u-boot 2020.01 that mender uses by default. Using version 2019.01 works just fine.