chradev

Dear All, While talking with our potential customers we found one uncovered GPR problem – the big “blind” range of antennas especially at bigger penetration. For now this problem is solving with a few scans with different antennas having different central frequencies, maximal penetrating depths and “blind” ranges respectively. Unfortunately, this approach has many disadvantages like more time for multiple scans, difficulties at synchronization of independent data, bigger archives etc. Our EGPR Application Controller is capable to capture data from many GPR antennas simultaneously and the software which can synchronize them at visualization effectively. That is why we start looking for an interest to extend our EGPR product in this new direction. Any comments and recommendations are welcome. Best regards EGPR Team

Hi to All, I would like to inform you about my post on Lime2-eMMC board application in Ground Penetrating Radar (GPR) system. I would also like to express our gratitude to Armbian project, its whole team and everybody here in for the great effort and help. Best regards Chris

Hi to All, I am proud to announce that our effort to embed Olimex' Lime2-eMMC board in Application Controller for Ground Penetrating Radar (GPR) systems meets with success to the final phase. Our product EGPR (Easy Ground Penetrating Radar) is ready for demo and field tests. Everybody can take a look on our just finished web site. There is link to the real application from Demo page. We would like to express our gratitude to Armbian project, its whole team and everybody here in for the great effort and help. Best regards EGPR team

Hi Sooperior, I also have many problems with USB OTG on Lime2 (A20) boards and customized Armbian build with mainline Kernel. The problems and some of the solutions are described in some posts on this forum thread. Best regards Chris

Hi Berkovsky, I have similar problem with Lime2-eMMC (A20 & AXP209) board and customized Armbian build always using latest mainline Kernel versions (4.8.10 at the moment). The problem is discussed from here to here but some HW dependency on UART0 RxD was found. Can you check if the bug disappears in case of serial console disconnecting if one is used. Best regards Chris

Thanks Zador, Unfortunately, you will not be able to test my use case because I have additional interconnection board and use GPIO-1 to connect console instead of Lime2 console connector. BTW the difference is a protection diode and power up resistor for UARD0 RxD line in case of connecting console via Lime2 console connector. In case of connecting it via GPIO-1 connector the line goes directly to chip pins. On the other hand all power on / off and reset functionality of Lime2 board is based on PMU chip (AXP209) and pushing PWR button have to power off the board in presence of DC-IN and battery. Best regards Chris

Hi to All, After setting rootfs read only I have found a problem with RPI Monitor. I have change RPI Monitor setup like described here. Because I have second SSD partition mounted on '/app/data' and used for writing I have changed: /usr/share/rpimonitor/web/stat -> /app/data/rmon/stat link to point to a folder on rw ssd rw partition and: daemon.datastore=/app/data/rmon in /etc/rpimonitor/daemon.conf. After starting the system RPI Monitor 'statistics.html' web page works fine but 'status.html' - not. All information on 'status.html' web page is accessible but it does not change showing 30-40 sec up time. This is probably the time the system is moving rootfs from rw to ro mode. Moving the rootfs to rw mode make 'status.html' web page to work fine again. I have also try to move all staff of '/usr/share/rpimonitor/web' folder to rw ssd partition but the problem stays there. BTW /etc and /var folders have rw layer (tempfs) mounted by unionfs-fuse and there is no other side effects observed for now. Any ideas where could be the problem? Best reagrds Chris

Thanks Zador, It can be but it cannot explain that when USB to serial adapter is connected to Lime2 console connector no such problem. I will try to find some test case based on your supposition. Best regards Chris

Hi Neomanic, I am using OTG in host mode for a long time and have other problem. When my STM32-H405 board is connected as CDC device and communication (~160 kbps from H405 to Lime2) is started for a long periods of time (5-10 hours) without apparent reason device is disconnected but continue to be visible by 'lsusb' command. The only way to revert to working state is by rebooting the system. A few months ago (earlier Kernel version) this problems have been happened much more frequently - after 1-2 hours. My investigation shown that some changes to musb driver have made the things better but did not solve the issue. That is why I have decided to use USB Host ports for critical communications and USB OTG for optional once. Best regards Chris

Thanks Dottgonzo, After your words I am definitely more peaceful. Best regards Chris

Hi to All, I have succeeded to get rootfs in read only mode but using unionfs-fuse instead of overlayfs & overlayroot. The idea is offered and reported here. It is also applied for RPi. Of course some change has to be applied because of using Kernel command line for rootfs options instead of /etc/fstab. Best regards Chris

Hi to All, The problem with rebooting instead of powering off looks more strange after last my findings. If brake off the console connection the board is powering off as before. EDIT: Disconnecting console RxD only is enough the problem to disappear. Main difference with the situation before the rise of this problem is that console and power button are connected via additional interconnection board. For wiring the console is used GPIO-1 connector. Additional wires are used for second power button wired in parallel to the Lime2 PWR one and mounted on the interconnection board for accessing it from the front panel. Any ideas where the problem is coming from? Best regards Chris

Thanks for your suggestion Dottgonzo, I tried it and succeeded out-of-the-box following your description also applied for RPi. Of course there was a small obstacle because in my use case rootfs options are transferred from uboot to kernel via its command line but it can be solved by a small change in mount_unionfs script. Fortunately, simplicity and long life time (9+ years) of the project are more important for me at the moment than possible speed lost. The only question for now is can we rely on Debian support to continue? Best regards Chris

Hi Lauhub, Why did you base your solution on Debian Jessie and Ubuntu overlayroot package while it is available in Xenial? As I have noted here the problem is probably the same in both cases. Any way I will try your modification a.s.a.p. Best regards Chris

Thanks Zador, Implemented backwards compatibility solves the problem with verbosity. Sorry for the question. Unfortunately, I have no time to look and understand all commits done. About rebooting instead of powering off this is the log with extended verbosity: The only fail: [FAILED] Failed to start Store Sound Card State. is not a problem because it exists for months. No other crashes especially the Kernel once. Unfortunately, I cannot say when this begins because relatively long time passed from my previous builds. Best regards Chris