Heisath

  • Posts

    226
  • Joined

  • Last visited

Reputation Activity

  1. Like
    Heisath got a reaction from freed00m in Kobol Helios64 on Sale   
    Added to watchlist. If it stays cheap enough, I'll buy it. 
     
    Can't guarantee you "Supported" flag, but I will have it running edge and notice problems
     
     
  2. Like
    Heisath got a reaction from IcerJo in Kobol Helios64 on Sale   
    Added to watchlist. If it stays cheap enough, I'll buy it. 
     
    Can't guarantee you "Supported" flag, but I will have it running edge and notice problems
     
     
  3. Like
    Heisath reacted to Pali in MVEBU - Clearfog PCIe struggles   
    Hello @Heisath! This is known problem. QCA98xx wifi chips are buggy, have timing and detection issues related to PCIe, which Qualcomm confirmed. Qualcomm recommendation is to increase PCIe pulse detection and for some (x86) motherboards, vendors released a new BIOS which do it. To make it worse, Marvell A38x SoC has also buggy PCIe which cause other issues and therefore combination of QCA98xx and A38x cause even more issues.
     
    I'm preparing patches for pci-mvebu.c kernel driver to fix some issues, but they are not ready yet.
     
    For QCA98xx I have prepared patch which are currently on linux-pci mailing list: https://lore.kernel.org/linux-pci/20210505163357.16012-1-pali@kernel.org/
     
    Could you test it and check if it helps with new kernel versions?
  4. Like
    Heisath reacted to tparys in initramfs-tools not fully installed on Debian Stretch with Armbian Linux 4.19.56-mvebu64   
    EspressoBin is currently in CSC support, so best to submit bugs/questions in in Peer to Peer Support.
     
    Also need to submit armbianmonitor output. It seems dumb, but there's a lot of necessary information in there.
     
     
    However, in this case, it tells you exactly what died. You've somehow uninstalled busybox (directly or indirectly), and initramfs-tools can't work properly without it.
     
     
    Not advisable. The initramfs-tools package generates the initrd file for the kernel, which is generally a required part of the boot process. You'll want to get this fixed, and probably not reboot in the meantime until you do.
  5. Like
    Heisath got a reaction from lanefu in Upgrading to Bullseye (troubleshooting Armbian 21.08.1)   
    Something that's probably gonna keep happening if nobody is using the beta repository (nightly/edge) and reporting errors before they make it to the current version. 
    FYI there is no Helios64 in Armbians testing "facility"
  6. Like
    Heisath got a reaction from gounthar in How would you implement a super precise clock with a board running Armbian?   
    Hi,
     
    how long does the time have to stay within the 1/60th of a second requirement? Minutes? Hours?
     
    I think there are tutorials out there on how to use common GPS modules (ebay search for raspi gps gives some), most of the ublox ones also have a rather precise timing output. From the website (ublox) it seems the also sell modules explicitly made for time synchro.
    Depending on how long you want to keep the devices in sync it might be acceptable to only sync them before you start filming (?) and have the device clock continue when gps goes away. 
     
    If a really precise clock is required I would maybe turn away from SBCs (boards with multithread, multiprocessors) have a tendency to have problems with jitter (obv. reasons).   If you need a precise time (as in your link) I'd suggest going for a simple microcontroller. There you can grab the GPS signal once, and then setup an internal timer - which are pretty precise considering the micro does only a thing at a time (if you go for cheap AVR ones). Afterwards just have the timer run out every 1/60th of a second and toggle a IO pin. Time reference done.
     
    EDIT: Bonus: If you are in Europe (although other regions probably have similar services) you could also use DCF77 to do the initial sync.
  7. Like
    Heisath got a reaction from hartraft in eMMc drive filled to 90% overnight and no idea why.   
    might need to do 
    sudo ncdu -x /  
    Then you can navigate through a tree-view, and figure out where the size comes from. 
     
    As a general step-by-step guide:
    - use "df -h" (or something like that), to figure out which device / mountpoint is getting full
    user@builder:~$ df -h Filesystem Size Used Avail Use% Mounted on tmpfs 1,6G 1,2M 1,6G 1% /run /dev/sda3 79G 31G 44G 41% / tmpfs 7,9G 0 7,9G 0% /dev/shm tmpfs 5,0M 0 5,0M 0% /run/lock tmpfs 4,0M 0 4,0M 0% /sys/fs/cgroup /dev/sda2 94M 5,2M 89M 6% /boot/efi tmpfs 1,6G 136K 1,6G 1% /run/user/1000 We now know, /dev/sda3 is fullest, and is mounted on /
     
    - next use "sudo ncdu -x /" to check the contents / where the space goes:
    ncdu 1.15.1 ~ Use the arrow keys to navigate, press ? for help --- / -------------------------------------------------------------------------- 17,2 GiB [##########] /home 8,5 GiB [#### ] /usr 2,0 GiB [# ] swapfile 1,0 GiB [ ] /var 760,0 MiB [ ] /root 508,4 MiB [ ] /opt 251,1 MiB [ ] /boot 11,6 MiB [ ] /etc 68,0 KiB [ ] /tmp 36,0 KiB [ ] /snap e 16,0 KiB [ ] /lost+found 8,0 KiB [ ] /media e 4,0 KiB [ ] /srv e 4,0 KiB [ ] /mnt e 4,0 KiB [ ] /cdrom @ 0,0 B [ ] libx32 @ 0,0 B [ ] lib64 @ 0,0 B [ ] lib32 @ 0,0 B [ ] sbin @ 0,0 B [ ] lib @ 0,0 B [ ] bin Total disk usage: 30,1 GiB Apparent size: 28,8 GiB Items: 789697 We see that most storage goes to /home, /usr and the swapfile.
     
    As the interface is interactive, you can just navigate down the folder structure to find the culprit.
  8. Like
    Heisath got a reaction from clostro in eMMc drive filled to 90% overnight and no idea why.   
    Use a tool like ncdu to figure out which folder(s) are getting so big. Then look into them.
  9. Like
    Heisath got a reaction from meymarce in Armbian 21.05.2 Focal with Linux 5.10.35-rockchip64: fancontrol die in error, fans not spinning   
    Just to clarify, was this a problem with 21.05.1 or IS it still a problem with 21.05.2? 
    If it is still active problem, we should seek to do a Pullrequest to fully fix it in the buildsystem.
     
    EDIT: Seems to be correct in the buildsystem: https://github.com/armbian/build/blob/3b3d85e25c2ecde30df7b5274fc6f1b9c0299ea2/config/sources/families/include/rockchip64_common.inc#L395-L401
  10. Like
    Heisath got a reaction from Groove On in Armbian 21.05 Jerboa   
    https://docs.armbian.com/Release_Changelog/#v2105-2021-05-09
  11. Like
    Heisath got a reaction from jock in Armbian 21.05 Jerboa   
    https://docs.armbian.com/Release_Changelog/#v2105-2021-05-09
  12. Like
    Heisath got a reaction from Werner in Armbian 21.05 Jerboa   
    https://docs.armbian.com/Release_Changelog/#v2105-2021-05-09
  13. Like
    Heisath got a reaction from Werner in Armbian v21.05 (Jerboa) Release Thread   
    Nah, all good from here. I'll try to do the release this sunday. Might hop in the IRC if I need assistance. Release on sunday evening is good IMHO because if something critical goes wrong, we can fix on monday.
  14. Like
    Heisath got a reaction from jock in Armbian v21.05 (Jerboa) Release Thread   
    Nah, all good from here. I'll try to do the release this sunday. Might hop in the IRC if I need assistance. Release on sunday evening is good IMHO because if something critical goes wrong, we can fix on monday.
  15. Like
    Heisath got a reaction from Igor in Armbian v21.05 (Jerboa) Release Thread   
    Nah, all good from here. I'll try to do the release this sunday. Might hop in the IRC if I need assistance. Release on sunday evening is good IMHO because if something critical goes wrong, we can fix on monday.
  16. Like
    Heisath got a reaction from lanefu in Armbian v21.05 (Jerboa) Release Thread   
    Hi,
     
    so I merged master into release candidate branch.  Can you please check the Jira issues that are still "In Progress", or can I assume they are all not done? Or are some expected to be closed in May?
     
    https://armbian.atlassian.net/secure/RapidBoard.jspa?rapidView=2&projectKey=AR
  17. Like
    Heisath reacted to tparys in I want to use the arduino board to detect the distance in three directions at once   
    Not that I have experience with these sensors, but looks like the general flow is this:
    hit the sensor with a pulse (low/high) count cycles until a response (pulseIn) As it's a microcontroller, pulseIn will probably not return until there is a response. The second call to pulseIn() probably starts counting after you're done printing the value from the first. Considering your output pulses happen within 2-10 ms of each other, I bet this happens:
     
    digitalWrite(center_Trig, LOW); digitalWrite(right_Trig, LOW); a=pulseIn(left_Echo, HIGH) / 58.00; Serial.println(a); // <- 2nd, 3rd echos arrive here b=pulseIn(center_Echo, HIGH) / 58.00; // <- timeout Serial.println(b); c=pulseIn(right_Echo, HIGH) / 58.00; // <- timeout Serial.println(c);  
    Maybe pulse the second sensor after you're done reading the return from the first? Then the third when the second is done?
     
  18. Like
    Heisath got a reaction from tparys in I want to use the arduino board to detect the distance in three directions at once   
    To add to @tparysexcellent answer:
     
    The original code with commented problems:
     
    const int left_Trig = 1; const int left_Echo = 2; const int center_Trig = 3; const int center_Echo = 4; const int right_Trig = 5; const int right_Echo = 6; float a; float b; float c; void setup() { Serial.begin(9600); pinMode(left_Trig, OUTPUT); pinMode(center_Trig, OUTPUT); pinMode(right_Trig, OUTPUT); pinMode(left_Echo, INPUT); pinMode(center_Echo, INPUT); pinMode(right_Echo, INPUT); Serial.println("Ultrasonic sensor:"); } void loop() { digitalWrite(left_Trig, LOW); delayMicroseconds(2); digitalWrite(center_Trig, LOW); delayMicroseconds(2); digitalWrite(right_Trig, LOW); delayMicroseconds(2); // Why the delay when turning them all off? Why not just turn all low at the same time? digitalWrite(left_Trig, HIGH); delayMicroseconds(10); digitalWrite(center_Trig, HIGH); delayMicroseconds(10); digitalWrite(right_Trig, HIGH); delayMicroseconds(10); // Delay after turning each one on, guarantees at this point the left one was on for 30µs already, the center for 20µs and the right one for 10µs that cant be right? // maybe again turn them all on, then wait 10µs? digitalWrite(left_Trig, LOW); digitalWrite(center_Trig, LOW); digitalWrite(right_Trig, LOW); // this seems ok a = pulseIn(left_Echo, HIGH) / 58.00; Serial.println(a); b = pulseIn(center_Echo, HIGH) / 58.00; Serial.println(b); c = pulseIn(right_Echo, HIGH) / 58.00; Serial.println(c); // this has problems because as tparys assumed pulseIn blocks. So the first pulseIn waits for the first echo, but then the second and so on might have been already missed! // https://www.arduino.cc/reference/en/language/functions/advanced-io/pulsein/ a = (int(a * 100.0)) / 100.0; b = (int(b * 100.0)) / 100.0; c = (int(c * 100.0)) / 100.0; // not sure what you are trying to do here? Multiply by 100 then divide by 100 just gives 1. So might just scrap it? Serial.println(a); Serial.println(b); Serial.println(c); Serial.println(); delay(10); }  
     
    Improved code, using one function to get rid of duplication and read one sensor after the other:
    const int left_Trig = 1; const int left_Echo = 2; const int center_Trig = 3; const int center_Echo = 4; const int right_Trig = 5; const int right_Echo = 6; float a; float b; float c; void setup() { Serial.begin(9600); pinMode(left_Trig, OUTPUT); pinMode(center_Trig, OUTPUT); pinMode(right_Trig, OUTPUT); pinMode(left_Echo, INPUT); pinMode(center_Echo, INPUT); pinMode(right_Echo, INPUT); Serial.println("Ultrasonic sensor:"); } void loop() { a = getEchoTime(left_Trig); // use a funtion here to get rid of the duplicate code b = getEchoTime(center_Trig); c = getEchoTime(right_Trig); Serial.println(a); Serial.println(b); Serial.println(c); Serial.println(); delay(10); } float getEchoTime(int channel) { digitalWrite(channel, LOW); delayMicroseconds(2); // turn channel of, and wait digitalWrite(channel, HIGH); delayMicroseconds(10); // turn channel on, then wait 10µs digitalWrite(channel, LOW); // turn off, total pulse time 10µs return pulseIn(channel + 1, HIGH) / 58.00; // use +1 here, as the echo channel seems to be trigger channel + 1 }

    An even better way would be to use interrupts (either external or pinchange) as this would allow you to fire the pulse and then do something else while waiting for the echo. I'm sure there are plenty of tutorials out there on how to read ultrasonic sensors in arduino without blocking.
     
     
  19. Like
    Heisath got a reaction from Werner in Armbian v21.05 (Jerboa) Release Thread   
    Code freeze has happened.
     
    I have branched an rc version (https://github.com/armbian/build/tree/v21.05.0-rc ) please send bugfixes here (additionally to the master branch).
     
    Also the version of the master branch has been set to 21.08.0-trunk.
     
    Please check the remaining Jira and Github PRs to see if anything in Jira needs closing (will be used to generate the changelog). 
     
    Testing and Bugfixing will be until beginning of May.
     
    Kind regards,
    Heisath
  20. Like
    Heisath got a reaction from Igor in Armbian v21.05 (Jerboa) Release Thread   
    @those who didnt make it: 
     
    No problem, just check the meeting log http://meeting.armbian.de/ , the irc chat log (irc.armbian.com/logs) and the Jira issues for the next release (https://armbian.atlassian.net/secure/RapidBoard.jspa?projectKey=AR&rapidView=2)
     
    @all:
     
    For the next weeks, remember to try and fix Jira issues (also mark them as done), review open PRs and issues on github. And try to get your work done before the codefreeze 2021-04-19 (Monday April 19th).
     
    @Igor:
    Wouldn't say so. I asked about the holiday thing in first post, also with note to possible reschedule. People could've said something beforehand
     
    @the new release dude:
    Show yourself! It's easy and a good way to help the project without  needing to get all technical.
  21. Like
    Heisath got a reaction from Technicavolous in Can someone tell me what does R6 in this LM358 circuit diagram do?   
    You can plug the circuit in some simulator (like falstad.com, LTSpice or similar) to check what the parameters do. 
    I did that for you here: https://tinyurl.com/yemxbzmt  As you guessed R6 in combination with LM358 B does work as a schmitt trigger.
     
    See also this circuit with just the B half. https://tinyurl.com/yehg4ooh
     
    The exact size of R6 probably does not matter all that much.
  22. Like
    Heisath got a reaction from pierre in Only LED8 light up...!?   
    @Mangix probably not, if he hasn't used it for a few months.
     
     
    @pierre LED 8 is the power led, if nothing else shows (not even LED1 / 2 which are system / error) I'd assume your board is not even starting and your SD card might be corrupt. 
    For further debugging you'll need to attach a computer to the micro usb and listen with some serial terminal to the output (and post it here). Or you could burn another SD card and try with that one.
     
    For LED meaning: https://wiki.kobol.io/helios4/hardware/
    For Setup (also includes connecting serial terminal): https://wiki.kobol.io/helios4/install/
  23. Like
    Heisath reacted to Alberto in driver compilation   
    Hello everyone.
    I have to change drivers code  in
    ./cache/sources/linux-mainline/linux-5.10.y/sound/soc/codecs/
    Which is the best way to compile a single sound driver without building all the kernel and without lost modification. I would like to work in my Ubuntu pc build Armbian directory.
  24. Like
    Heisath got a reaction from Tido in Need your help - what else beside Etcher   
    I have used USBImager for the last few sd card writes. Works well. 
  25. Like
    Heisath got a reaction from Myy in Armbian v21.05 (Jerboa) Release Thread   
    Release Planning: April 3rd. Meeting in IRC channel #armbian on freenode. Meeting starts at 2pm GMT.
    (let me know if this is a bad date, because it is around easter holiday in Germany for example)
     
    Code Freeze: 2021-04-19 (Monday April 19th)
    Release Date: 2021-05-09 (Sunday May 9th)
    Release Candidate: https://github.com/armbian/build/tree/v21.05.0-rc
    Changelog: https://docs.armbian.com/Release_Changelog/#v2105-2021-05-09
    Coordinator: @Heisath
     
    The goal of this thread is to discuss testing, bugfixes, and the overall quality of the release. 
     
    Open topics:
    - complete desktop branch merge into master (this seems generally done, but might need fine tuning)
    - enable 3D support (also done? Bugfixing)
    - discuss support for desktops (IIRC it was planned to have a longer supported LTS desktop version, we need a maintainer for that, if it happens)
    - check if remaining boards can / have been updated to LK5.10 (some were left out last release)
    - check possible u-boot updates
    - complete remaining Jira issues
    - cycle and check board support status (espressobin for example needs a new maintainer (otherwise EOS) @Pali maybe?)
    - late topics: 
    - business meeting schedule
    - kernel config changes on arm64
     
    Release Planning Meeting Agenda:
     
    Please add developers and more topics below, I will then also add them here.
    @Myy @TonyMac32 @balbes150 @piter75 @sfx2000 @ebin-dev @chwe @ning @lanefu @gprovost @aprayoga @5kft @JMCC @martinayotte @going @jeanrhum @dolphs @jock @belfastraven @TRS-80 @Bozza @Rich Neese @sgjava @Mangix @Pali