Thumbs Up Konrad ! CQ LoRa Chaters …
Don
1 Like
Upcoming project: 1240-1300 MHz antenna. Yagi loop beam?
–Konrad
Jeremías,
It’s streamed rather than being delivered as a file like everything else is.
–Konrad
It’s streaming now!
1 Like
It is much more stable, slight skipping and the occasional loop, which recovers fairly quickly.
Had to reboot to get the audio going, same report as you now. every 5 or ten seconds there is a slight skip.
My snr -6 with 100% valid packets
1 Like
@Abhishek
@Syed
I find that I have to reboot when the audio gets to about 4,721,276 packets. The audio part of the receiver seems to hang at that point. All other functions appear to be normal, just that the audio stops playing.
1 Like
good catch. thanks!
I was planning on saying something about it. It seems like the audio would drop out after a day or so. A restart would correct this. Although, I haven’t had time to investigate further.
@Abhishek
@Syed
Yesterday the audio quit at 287,101 frames. I re-booted this morning and it did start playing again. I don’t know the content, but it seems to not be consistent as to when it quits. Perhaps the type of audio at the points of cessation?
@Syed would it be possable to make the audio stream available via the outernet web interface?
1 Like
@Abhishek
My Dreamcatcher now totally locks up about every two days. Requiring a re-boot.
From the log viewer >> system messages here is the last entry before reboot
Jul 9 22:15:17 outernet user.info ondd[680]: [carousel] completed: opaks/b3e0-Louis_Walsh.html.tbz2
Jul 9 22:23:30 outernet user.notice root: Discovered /mnt/downloads/opaks/23f9-messages-2018-07-09_22_22.txt.tbz2, extracting…
Jul 9 22:23:30 outernet user.info ondd[680]: [carousel] completed: opaks/23f9-messages-2018-07-09_22_22.txt.tbz2
Jan 1 00:00:20 outernet syslog.info syslogd started: BusyBox v1.24.1
Jan 1 00:00:20 outernet user.notice kernel: klogd started: BusyBox v1.24.1 ()
Jan 1 00:00:20 outernet user.info kernel: [ 0.000000] Booting Linux on physical CPU 0x0
Jan 1 00:00:20 outernet user.notice kernel: [ 0.000000] Linux version 4.10.6 (abhishek@alpha) (gcc version 6.1.0 (Buildroot 2016.02-git) ) #1 SMP 2018-01-01
Then during reboot many “recovery actions in F2FS-fa” like this at boot time of 00:00:20
Jan 1 00:00:20 outernet user.info kernel: [ 3.197788] cloop: skylark-dc-1804301810.ksop: 2018 blocks, 65536 bytes/block, largest block is 65562 bytes.
Jan 1 00:00:20 outernet user.debug kernel: [ 3.221284] ISO 9660 Extensions: RRIP_1991A
Jan 1 00:00:20 outernet user.info kernel: [ 3.281071] usb 1-1: new high-speed USB device number 2 using ehci-platform
Jan 1 00:00:20 outernet user.notice kernel: [ 4.244562] F2FS-fs (mmcblk0p4): recover_inode: ino = ad79, name = 0608cf0ae9287d043d8ce56c0821c2066cac411aaf22428aaa56a02c448f964c
Jan 1 00:00:20 outernet user.notice kernel: [ 4.258539] F2FS-fs (mmcblk0p4): recover_dentry: ino = ad79, name = 0608cf0ae9287d043d8ce56c0821c2066cac411aaf22428aaa56a02c448f964c, dir = 9, err = 0
Jan 1 00:00:20 outernet user.notice kernel: [ 4.272530] F2FS-fs (mmcblk0p4): recover_data: ino = ad79 (i_size: recover) recovered = 1, err = 0
Jan 1 00:00:20 outernet user.notice kernel: [ 4.281531] F2FS-fs (mmcblk0p4): recover_inode: ino = ad79, name = 0608cf0ae9287d043d8ce56c0821c2066cac411aaf22428aaa56a02c448f964c
Jan 1 00:00:20 outernet user.notice kernel: [ 4.293565] F2FS-fs (mmcblk0p4): recover_data: ino = ad79 (i_size: recover) recovered = 1, err = 0
@ac8dg
@Abhishek
The blockage seems to happen at odd intervals. The stop at 4,721,276 frames is the longest the receiver has played audio; when I re-booted that time, it only played 287,101 frames until it locked up. I re-booted again, and early that day it hung up at 46,236. Not consistent as far as what we can see at this end. I am not seeing any other problems with the receiver other than the audio lock-ups.
Do the audio lockups impact any other part of receiver operations?
My lockups where the audio stops doesn’t lock up the rest of the outernet device that I can tell yet.
@Syed
@Abhishek
I am not seeing any other problems that would relate to the audio lock-up. I re-started this morning and am seeing 748,975 frames played so far, and continuing. It has been at unusual/not the same number of frames in each incident. I have noted 4,721,276, then 287,101, then 46,236, then 356,101 at lockup so far, each required a re-start of the receiver to continue to play. It appears that the receiver is still seeing the audio frames coming, but is not counting or playing after this occurs. Relating to @ac8dg Jim’s log above, I did note that in one log file it stated that the receiver is not compatible with f2fs-fs, however, I am not knowledgeable enough of the system to know if that is a concern relating to this situation.
I have two different types of “lock-up”. Yesterday, everything was locked, the led5 (busy) was dim, the led6 (pck1) and led10 (audio) had stopped flashing. The wifi was also not functional.
Today, I had just the audio service stop, but the radio and data was still operating and getting “data”. Just the led10 had stopped flashing. A reboot got things back to normal.
So… maybe they are two things going on causing different results. Bottom line, something happens everyday or so requiring a re-boot. not good.
@ac8dg you can debug this easily using a UPS power bank or of course a classic APC UPS
Dreamcatcher Case for Travel - #6 by kenbarbi?
