First of all we would like to apologize for delays in translation of the German tutorials and forum discussions. We are trying our best to keep our non German speaking customers informed but it is so much material that the English section is far behind the German versions. We hope to get this job better done in the future. If anyone out there would like to help us please feel free to send us an Email... we might have a job for you.
It is part of our "Revolution Pi" to keep up a very open and honest communication with our community. This includes trustfully talking about bugs and faults. Today it is time again to give you a short report about known problems and bugs and how we resolved them:
1) Gateway modules
Some customers experienced dysfunctions when using our gateway modules in continuous operation. We have examined these dysfunctions and finally found the reason. Under certain cirumstances timeouts may happen in PiBridge communication with gateway modules. So we diligently checked the gateway communication driver and patched it so that gateway communication now is fluent and should run without dysfunctions. If you are running an installation with RevPi and gateway modules we strongly recommend to do a "sudo apt-get upgrade" on such installations to get the newest kernel version on your Core. All RevPi Core 3 leaving our production line do have the newest version on their image since last week. Also the downloadable Jessie image on our server has the newest version of all packages (as at 8th August). There is no firmware update for the gateways (this had been communicated incorrectly in some discussions in the German forum). Although we have resolved the problems we strongly recommend not to use CM1 if you are using 2 gateway modules. You should use CM3 (RevPi Core 3) instead in order not to suffer from performance problems. Gateway communication is using a high portion of CPU power and with CM1 you might experience huge setbacks in system performance.
You might have already detected some problems with our new "advanced configuration" section for virtual devices like "Modbus Master": When deleting lines in the middle of a task list your configuration might get stuck. We have solved that bug and you can "sudo apt-get upgrade" to get the corrected packages. Other problems with the Modbus Master configuration which have been reported in German forum has been examined and we've found the reason being a slow network between browser and web server. We are trying to get the web server more preformant for the next official release.
3) Virtual devices "Modbus Master / Slave"
Sorry, but with the last Jessie release we have got a start up problem with these Modbus stacks: When resetting or cold starting the system you had to run "piTest -x" to manually start these drivers. We have fixed that bug and now the drivers will automatically start when booting the system as long as you have configured the drivers to be active (you can do this on the devices web configuration utility). There has also been a bug when using multiple "read single coils" in sequence. When you defined more than 8 such tasks for a Modbus Master (instead of just using a single "read multiple coils") you had got wrong values in the process image for the coils. This bug has been fixed with the new package too.
4) TeamViewer RevPi
The advertised TeamViewer RevPi agent only now is integrated in the images of the RevPi Core 3 comming out of production line. If you go on the status page of the device's web server where the services can be activated or deactivated and you do not find the TeamViewer Revpi on this list you have got a system without that agent being installed. But you can easily install it yourself. There is a German tutorial for it (sorry no English version yet but you might get the point by watching the screen dumps...).
5) Misunderstanding when using the instruction for upgrading Wheezy to Jessie
Users have misunderstood the instructions when trying to port setup files from Wheezy to Jessie: They have copied the whole configuration files listed in the last chapter of the tutorial from the old system to the new one instead of just copying their private content which they wanted to save. But by copying the complete file they have overwritten important system settings. E.g. by copying the old config.txt you ruin the device tree which results in dysfunctions when trying to read the cryto chip's information - thus prohibiting any further login on the web pages of the Core. So please if you upgrade from Wheezy to Jessie and you want to save old settings please be careful and you should better consult a Linux freak if you are not very deep in this matter.
6) Problems with the Compute Modules socket in RevPi Core 3 devices
We apologize causing problems for a view of our customers caused by great differences in quality of the SODIMM sockets used for the CM3. Although we have passed extensive mechanical tests with this product including a shaker with extreme accelerations and vibrations, some of the devices did not survice the transportation to the customer. In these cases the CM3 had lost contact to the socket and in a few cases even slipped completely out of that socket due to loose spring load of the socket mechanics. All of the known customers already have got replacements. We have decided to solve the problem ad hoc by a 2 component adhesive which fixes the CM3 to the sockets brackets. We also decided to preventively use 2k heat conducting adhesive instead of adhesive foil to hold the heat sink in place on the Broadcom SOC. All systems delivered since the last 2 weeks have been assembled this way. In the medium term we are preparing a new revision of the pcb which will use screw terminals to hold the CM3 in place.
If you have received your RevPi Core 3 before mid of July and you have successfully installed and tested your system on a DIN rail in a cabinet there is absolutely now reason to fear any risk. In such an environment the system will definitly not experience the high accelerations and vibrations it is exposed to during transport. But if you have just taken the device out of the transport box and can't even get it to run you are suffering most likely from this problem and your device's socket was too weak to hold the CM3 in place during transport. In such a case you get substituted your device promptly and without any objection. If you are in doubt what to do just contact KUNBUS support and discuss your case with us.