Colby... last night I was playing with some of the other smart groups listed on the quadnet web site. When I tried ILLINK... I received the "not in cache" message. While I did try several more times... each time I continued to get that same message and was never able to actually log in. Is ILLINK misconfigured?
toggle quoted message
Show quoted text
On Wed, Apr 15, 2020 at 10:25 AM, Colby Ross W1BSB wrote:
When you get not in cache, key up again.
?
Nothing is in the cache when a hotspot or repeater first boots up. After the first not in cache, it should add the required information to the local cache on how to route to that group, so the 2nd call will go through successfully.
?
Colby
?
?
?
When I try to connect to the smartgroups on DSTAR1 or DSTAR2 or some local repeaters I am getting not in cache message, Any help would be appreicated
|
Re: QnetGateway + ID-4100A in Access Point Mode + ID51A Plus
That's really interesting. The ackTimer is used to detect when the Icom firmware is locked up and needs to be reset.
The ackTimer is only about moving packets from the internet to the radio. If you are in Terminal Mode, the AMBE data will be decoded and sent to the radio's speaker. In Access Point Mode, the voice stream will be sent directly to the GMSK modulator of the radio's transmitter.
Whenever a packet is received and sent to the radio, the ackTimer is started. THe radio is suppose to send an acknowledgement, one acknowledgement for a header packet and a different acknowledgement for a voice packet. Until qnitap receives the acknowledgement, it will stack up arriving packets in a queue. Once the acknowledgement is received, the next in the queue is sent to the radio.
The ackTimer "threshold" is the time in seconds when itap decides that the radio is foobar and needs to be reset. Resetting is a process where the serial port is closed, the running parameters are reset so that the initialization sequence will be read to go, the serial port is reopened and then the very last thing is to empty the queue and return to the normal processing loop, which will start by initializing the serial communication to the radio.
What I find fascinating is that AP need a bigger threshold than TM.
Did you try something in-between? The serial port reset takes less than 0.1 seconds, so moving the threshold from 60 milliseconds to 1.06 seconds is a very big change. This threshold is big enough to easily hear if the radio locks up during a voice stream, so trying something a litter smaller could make things better.
|
Re: Important new release
I was suspecting that card myself.. Colby is sending me info on a better card and I'll switch to it Wed or Thu (next shoppign trip) Oh the fun. First time for either of us using Team Viewer on a chromebook and it did not work as designed.. So he talked. i typed and success was ours.
"Nothing adds excitement like something that is none of your business" Note I am not a doctor, I don't even play one on television John F Davis
On Sunday, May 17, 2020, 10:53:48 AM EDT, Colby Ross W1BSB <colbypr@...> wrote:
John is all set. ? It appeared to be some file corruption likely caused by a faulty SD card. His qnitap is working flawlessly now. ? Colby ? ?
From: [email protected] < [email protected]> On Behalf Of John F Davis Sent: Sunday, May 17, 2020 07:08 To: [email protected]Subject: Re: [QnetGateway] Important new release ? Tried blowing it away (rm QnetGateway -f -r) ad redoijg the git command... Now I have a qnitap file but.. alas. still not working.
"Nothing adds excitement like something that is none of your business" Note I am not a doctor, I don't even play one on television John F Davis On Saturday, May 16, 2020, 04:50:26 PM EDT, Tom Early <n7tae@...> wrote: Systemd is not even starting qnitap.
This looks like the /lib/systemd/system/qnitap.service file is foobared. I sure would like to know how that happened.
Make sure there is only one file listed with a: ls -l /lib/systemd/system/qnitap*
Uninstall and reinstall the system. In fact, do a "ps -aux | grep qn | grep -v grep" right after you uninstall to see if there was anything still left running.
Also, can you post your qn.cfg file? qnadmin figures out how to do a "us" and "is" by what's in that file.
|
Re: Important new release
John is all set. ? It appeared to be some file corruption likely caused by a faulty SD card. His qnitap is working flawlessly now. ? Colby ? ?
toggle quoted message
Show quoted text
From: [email protected] < [email protected]> On Behalf Of John F Davis Sent: Sunday, May 17, 2020 07:08 To: [email protected]Subject: Re: [QnetGateway] Important new release ? Tried blowing it away (rm QnetGateway -f -r) ad redoijg the git command... Now I have a qnitap file but.. alas. still not working.
"Nothing adds excitement like something that is none of your business" Note I am not a doctor, I don't even play one on television John F Davis On Saturday, May 16, 2020, 04:50:26 PM EDT, Tom Early <n7tae@...> wrote: Systemd is not even starting qnitap.
This looks like the /lib/systemd/system/qnitap.service file is foobared. I sure would like to know how that happened.
Make sure there is only one file listed with a: ls -l /lib/systemd/system/qnitap*
Uninstall and reinstall the system. In fact, do a "ps -aux | grep qn | grep -v grep" right after you uninstall to see if there was anything still left running.
Also, can you post your qn.cfg file? qnadmin figures out how to do a "us" and "is" by what's in that file.
|
Re: Important new release
Tried blowing it away (rm QnetGateway -f -r) ad redoijg the git command... Now I have a qnitap file but.. alas. still not working.
"Nothing adds excitement like something that is none of your business" Note I am not a doctor, I don't even play one on television John F Davis
On Saturday, May 16, 2020, 04:50:26 PM EDT, Tom Early <n7tae@...> wrote:
Systemd is not even starting qnitap.
This looks like the /lib/systemd/system/qnitap.service file is foobared. I sure would like to know how that happened.
Make sure there is only one file listed with a: ls -l /lib/systemd/system/qnitap*
Uninstall and reinstall the system. In fact, do a "ps -aux | grep qn | grep -v grep" right after you uninstall to see if there was anything still left running.
Also, can you post your qn.cfg file? qnadmin figures out how to do a "us" and "is" by what's in that file.
|
Re: QnetGateway + ID-4100A in Access Point Mode + ID51A Plus
Hi Everyone;
After some troubleshooting I got it working, I had to change some code in QnetITAP.cpp;?? line 364.? (although that may not be accurate as I was doing some other edits in the file during my troubleshooting so plus or mines a few lines)
The code I changed is below (screenshot)... essentially just changed the tolerance of the ack timer.
Question:? not really knowing the code that well (at all), what are the implications of changing this threshold?
Thanks.
VY1RG
Thank you both Tom and Stephan for replying with your suggestions. ? I cannot reproduce the echo test that you have shown Stephen.? I was, until a few hours ago, certain there must be a defect with my 4100.? However, I decided to test the exact same radio setup, but with pi-star ... it worked.??? Seems like for whatever reason my 4100 in Access Point mode?+ QnetGateway just do not like each other.? What I find very strange is that it does work perfectly in Terminal mode, and that it works fine in AccessPoint mode with pi-star.
Hi Rob,
I just did a quick test by myself:
- ID-4100DH was set to 145.350 MHz Simplex + Accesspoint-Mode
- QNetGateway, version from 12th MAy 2020, linked to DCS003 Z,
which is an Echo-Reflektor
- ID-51E was programmed as follows:
??? ??? 
??? Inside the radio I choose this entry from the repeater list and
set the URCALL to CQCQCQ
???
I clould here back my Audio so everything worked as it should.
For your perusal, I also uploaded some pictures of my radio settings
as well as a real quick test video onto my DropBox Account for you:
vy 73 & 55 de Stephan 9V1LH / DG1BGS
Am 14/05/2020 um 09:03 schrieb Robert
Gillis:
Hi Tom;
Thanks for the suggestion.? Unfortunately this did not
change the behaviour. ??
Thinking it must be another setting on one of the radios I
actually just did a factory reset on both the radios and still
have the same behaviour once setting the frequencies, R1, R2,
etc... ? I do find it odd that I do receive all the metadata?
(I.e. the RX: line and the calls that are active) on the HT
but just no audio ? (Just for clarity, the HT does receive the
signal... just like there is noone talking - and yes the
volume is up. ).? I will try a few more things later this week
when my schedule allows for it.
Quite certain it is a 4100 problem, and not a QnetGateway
problem but I figured someone on this distribution list may
have ran into this problem before.
Thanks again for the suggestion.
Rob
On Wed, May 13, 2020 at 6:11
AM Tom Early < n7tae@...> wrote:
Make
sure your the offset is zero on your 4100. You'll have to get
out of AP mode because you can't set the offset while in that
modem.
After you return to normal mode, you shouldn't be in DR mode,
but your 4100 should display the frequency and indicate that
you are in DV mode. Then, enter the menu and select the top
menu item, "DUP/TONE", then select the Offset menu and set it
to zero.
|
Re: Important new release
I think you found it when I did the ls -l /lib/systemd/system/qnitap* "File not found" (well that's a simplified version)
"Nothing adds excitement like something that is none of your business" Note I am not a doctor, I don't even play one on television John F Davis
?
Also on the GREP commands you suggested.. What should happen and how fast (Seems nothing happened at all. just the cursor went away as it weere? like 20 minutes o fnothing)
On Saturday, May 16, 2020, 04:50:26 PM EDT, Tom Early <n7tae@...> wrote:
?
?
Systemd is not even starting qnitap.
This looks like the /lib/systemd/system/qnitap.service file is foobared. I sure would like to know how that happened.
Make sure there is only one file listed with a: ls -l /lib/systemd/system/qnitap*
Uninstall and reinstall the system. In fact, do a "ps -aux | grep qn | grep -v grep" right after you uninstall to see if there was anything still left running.
Also, can you post your qn.cfg file? qnadmin figures out how to do a "us" and "is" by what's in that file.
|
Re: QnetGateway + ID-4100A in Access Point Mode + ID51A Plus
Thank you both Tom and Stephan for replying with your suggestions. ? I cannot reproduce the echo test that you have shown Stephen.? I was, until a few hours ago, certain there must be a defect with my 4100.? However, I decided to test the exact same radio setup, but with pi-star ... it worked.??? Seems like for whatever reason my 4100 in Access Point mode?+ QnetGateway just do not like each other.? What I find very strange is that it does work perfectly in Terminal mode, and that it works fine in AccessPoint mode with pi-star.
Hi Rob,
I just did a quick test by myself:
- ID-4100DH was set to 145.350 MHz Simplex + Accesspoint-Mode
- QNetGateway, version from 12th MAy 2020, linked to DCS003 Z,
which is an Echo-Reflektor
- ID-51E was programmed as follows:
??? ??? 
??? Inside the radio I choose this entry from the repeater list and
set the URCALL to CQCQCQ
???
I clould here back my Audio so everything worked as it should.
For your perusal, I also uploaded some pictures of my radio settings
as well as a real quick test video onto my DropBox Account for you:
vy 73 & 55 de Stephan 9V1LH / DG1BGS
Am 14/05/2020 um 09:03 schrieb Robert
Gillis:
Hi Tom;
Thanks for the suggestion.? Unfortunately this did not
change the behaviour. ??
Thinking it must be another setting on one of the radios I
actually just did a factory reset on both the radios and still
have the same behaviour once setting the frequencies, R1, R2,
etc... ? I do find it odd that I do receive all the metadata?
(I.e. the RX: line and the calls that are active) on the HT
but just no audio ? (Just for clarity, the HT does receive the
signal... just like there is noone talking - and yes the
volume is up. ).? I will try a few more things later this week
when my schedule allows for it.
Quite certain it is a 4100 problem, and not a QnetGateway
problem but I figured someone on this distribution list may
have ran into this problem before.
Thanks again for the suggestion.
Rob
On Wed, May 13, 2020 at 6:11
AM Tom Early < n7tae@...> wrote:
Make
sure your the offset is zero on your 4100. You'll have to get
out of AP mode because you can't set the offset while in that
modem.
After you return to normal mode, you shouldn't be in DR mode,
but your 4100 should display the frequency and indicate that
you are in DV mode. Then, enter the menu and select the top
menu item, "DUP/TONE", then select the Offset menu and set it
to zero.
|
Re: Important new release
Systemd is not even starting qnitap.
This looks like the /lib/systemd/system/qnitap.service file is foobared. I sure would like to know how that happened.
Make sure there is only one file listed with a: ls -l /lib/systemd/system/qnitap*
Uninstall and reinstall the system. In fact, do a "ps -aux | grep qn | grep -v grep" right after you uninstall to see if there was anything still left running.
Also, can you post your qn.cfg file? qnadmin figures out how to do a "us" and "is" by what's in that file.
|
Re: Important new release
Ok Here is the last quote a bit of the file. (entire file after a restart) Oh and for a period it told me ITAP not installed so I did an IS then a US and got the ITAP installed again but....
(I tried to start it once without the radio conected. I re-connected the radio and it went back to stopped)
pi@raspberrypi:~/QnetGateway $ sudo journalctl -u qnitap
-- Logs begin at Sat 2020-05-16 15:02:20 EDT, end at Sat 2020-05-16 15:05:19 EDT. --
May 16 15:04:27 raspberrypi systemd[1]: Started QnetITAP.
May 16 15:04:27 raspberrypi systemd[644]: qnitap.service: Failed to execute command: Exec format error
May 16 15:04:27 raspberrypi systemd[644]: qnitap.service: Failed at step EXEC spawning /usr/local/bin/qnitap: Exec format error
May 16 15:04:27 raspberrypi systemd[1]: qnitap.service: Main process exited, code=exited, status=203/EXEC
May 16 15:04:27 raspberrypi systemd[1]: qnitap.service: Failed with result 'exit-code'.
May 16 15:04:27 raspberrypi systemd[1]: qnitap.service: Service RestartSec=100ms expired, scheduling restart.
May 16 15:04:27 raspberrypi systemd[1]: qnitap.service: Scheduled restart job, restart counter is at 1.
May 16 15:04:27 raspberrypi systemd[1]: Stopped QnetITAP.
May 16 15:04:27 raspberrypi systemd[1]: Started QnetITAP.
May 16 15:04:27 raspberrypi systemd[649]: qnitap.service: Failed to execute command: Exec format error
May 16 15:04:27 raspberrypi systemd[649]: qnitap.service: Failed at step EXEC spawning /usr/local/bin/qnitap: Exec format error
May 16 15:04:27 raspberrypi systemd[1]: qnitap.service: Main process exited, code=exited, status=203/EXEC
May 16 15:04:27 raspberrypi systemd[1]: qnitap.service: Failed with result 'exit-code'.
May 16 15:04:27 raspberrypi systemd[1]: qnitap.service: Service RestartSec=100ms expired, scheduling restart.
May 16 15:04:27 raspberrypi systemd[1]: qnitap.service: Scheduled restart job, restart counter is at 2.
May 16 15:04:28 raspberrypi systemd[1]: Stopped QnetITAP.
May 16 15:04:28 raspberrypi systemd[1]: Started QnetITAP.
May 16 15:04:28 raspberrypi systemd[652]: qnitap.service: Failed to execute command: Exec format error
May 16 15:04:28 raspberrypi systemd[652]: qnitap.service: Failed at step EXEC spawning /usr/local/bin/qnitap: Exec format error
May 16 15:04:28 raspberrypi systemd[1]: qnitap.service: Main process exited, code=exited, status=203/EXEC
May 16 15:04:28 raspberrypi systemd[1]: qnitap.service: Failed with result 'exit-code'.
May 16 15:04:28 raspberrypi systemd[1]: qnitap.service: Service RestartSec=100ms expired, scheduling restart.
May 16 15:04:28 raspberrypi systemd[1]: qnitap.service: Scheduled restart job, restart counter is at 3.
May 16 15:04:28 raspberrypi systemd[1]: Stopped QnetITAP.
May 16 15:04:28 raspberrypi systemd[1]: Started QnetITAP.
May 16 15:04:28 raspberrypi systemd[654]: qnitap.service: Failed to execute command: Exec format error
May 16 15:04:28 raspberrypi systemd[654]: qnitap.service: Failed at step EXEC spawning /usr/local/bin/qnitap: Exec format error
May 16 15:04:28 raspberrypi systemd[1]: qnitap.service: Main process exited, code=exited, status=203/EXEC
May 16 15:04:28 raspberrypi systemd[1]: qnitap.service: Failed with result 'exit-code'.
May 16 15:04:28 raspberrypi systemd[1]: qnitap.service: Service RestartSec=100ms expired, scheduling restart.
"Nothing adds excitement like something that is none of your business" Note I am not a doctor, I don't even play one on television John F Davis
On Saturday, May 16, 2020, 02:00:25 PM EDT, Tom Early <n7tae@...> wrote:
Sorry guys, I'm working on too many thinks at once! I think I have fixed the trouble with the web page finally. Do a "git pull" to get a new index.php file.
John, you need to take a look at the qnitap log file. The maintenance menu may not be the way to go this time because when it starts, it only shows the last few lines. Try:
sudo journalctl -u qnitap
Then do a "G" to get to the end of the logfile (it may be long if QnetGateway has been running long, so it may take a sec or 2 to get to the end). Then you can back up with your arrow keys and see what's before the message from systemd about being shutdown. Look for the last few messages from qnitap.
It might help to shutdown the pi and the radio, unplug the digital cable, plug it back in, power up the radio and then the pi and see if that helps.
|
Re: Important new release
Sorry guys, I'm working on too many thinks at once! I think I have fixed the trouble with the web page finally. Do a "git pull" to get a new index.php file.
John, you need to take a look at the qnitap log file. The maintenance menu may not be the way to go this time because when it starts, it only shows the last few lines. Try:
sudo journalctl -u qnitap
Then do a "G" to get to the end of the logfile (it may be long if QnetGateway has been running long, so it may take a sec or 2 to get to the end). Then you can back up with your arrow keys and see what's before the message from systemd about being shutdown. Look for the last few messages from qnitap.
It might help to shutdown the pi and the radio, unplug the digital cable, plug it back in, power up the radio and then the pi and see if that helps.
|
Re: Important new release
Ok the error is in the modules seciton and I'm having an issue with the ITAP module.. bu totherwise it seems to be working
Now Module A (ITAP) is stopped. i go to Maintenance menu and re-start it. and when I exit that menu Still stopped. go back in and it's stopped again .? Stuck
|
Re: Important new release
515?
I just did another GP and it did not pull any .cpp or .h files so we will see.
Still getting the Uncaught Exception unable to pen database error.?
Have clue about the SQLte3 database will follow
Ok the error is in lime 10 of the index.php Assumign that i teh SQUlte3 database (since it also mentions that) which AL mentioned I tried renaming (not deleting) tje fie (Easier to restore it by renaming it back_) no joy? Suggestions please
I assume 515 is the version number of QnetGateway... If so I should be running it bui how do I figure that out???
Well after playing with it for a whle.. SUCCESS Other than restoring index.php to the original file name. I know not what I did that fixed it.?
?
Check that I still have the error messages but now I have last heard.. OK,? ?Error is now on line 180 of the index.php site.
|
Re: Important new release
Sorry John.
Robert also found an error with qnconfig. Both are fixed. Since these are not C++ files, you just need to do a "git pull" to patch you system, but only if you are running 515.
If "git pull" pulls down any *.cpp or *.h file, you need to uninstall and reinstall.
|
Re: Important new release
Well.. Since you pushed an upadat I did the IS-GP-US bit and
QnetGateway WA8YXM Dashboard
System Info:
CPU Kernel OS Hostname
Raspberry Pi Zero W Rev 1.1 temp=48.7¡ãC 4.19.75+ armv6l GNU/Linux Raspbian GNU/Linux 10 (buster) raspberrypi
Last Heard:
MyCall/Sfx Mod Via Time
Fatal error: Uncaught Exception: Unable to open database: disk I/O error in /home/pi/QnetGateway/index.php:155 Stack trace: #0 /home/pi/QnetGateway/index.php(155): SQLite3->__construct('/usr/local/etc/', 1) #1 {main} thrown in /home/pi/QnetGateway/index.php on line 155
"Nothing adds excitement like something that is none of your business" Note I am not a doctor, I don't even play one on television John F Davis
On Friday, May 15, 2020, 02:01:40 PM EDT, Tom Early <n7tae@...> wrote:
Thanks Al,
I pushed up a fix for that.
Tom N7TAE
|
Re: Important new release
Thanks Al,
I pushed up a fix for that.
Tom N7TAE
|
Re: Important new release
Thanks, Tom.
Just a heads-up: I had to delete my existing sqlite3 database (after uninstall/"us", before install/"is"), to get Last Heard stations to appear in the dashboard. Other than that, the update went smoothly. Thanks for all the great work!
73 de K7AJG . .
From: "Tom Early" <n7tae@...> To: "QnetGateway" < [email protected]> Sent: Monday, May 11, 2020 12:33:54 PM Subject: [QnetGateway] Important new release
Thanks to some persistent reminders from DS5HVM and corroboration from W1BSB, I have finally realized that there were problems with the way qngateway and qnlink were opening the sqlite3 database. When I was first developing the sqlite3 database support for QnetGateway, I was seeing some problems with my hot-spot, but I was solving the encountered problems the wrong way. This new release has backed out those solutions and database access is now properly coded, and the code is smaller, so I like that!
Please update your system at your earliest convenience. In the qnadmin main menu, uninstall your system (us), do a git pull (gp) and then install your system (is).
|
Re: QnetGateway + ID-4100A in Access Point Mode + ID51A Plus
Hi Rob,
I just did a quick test by myself:
- ID-4100DH was set to 145.350 MHz Simplex + Accesspoint-Mode
- QNetGateway, version from 12th MAy 2020, linked to DCS003 Z,
which is an Echo-Reflektor
- ID-51E was programmed as follows:
??? ??? 
??? Inside the radio I choose this entry from the repeater list and
set the URCALL to CQCQCQ
???
I clould here back my Audio so everything worked as it should.
For your perusal, I also uploaded some pictures of my radio settings
as well as a real quick test video onto my DropBox Account for you:
vy 73 & 55 de Stephan 9V1LH / DG1BGS
Am 14/05/2020 um 09:03 schrieb Robert
Gillis:
toggle quoted message
Show quoted text
Hi Tom;
Thanks for the suggestion.? Unfortunately this did not
change the behaviour. ??
Thinking it must be another setting on one of the radios I
actually just did a factory reset on both the radios and still
have the same behaviour once setting the frequencies, R1, R2,
etc... ? I do find it odd that I do receive all the metadata?
(I.e. the RX: line and the calls that are active) on the HT
but just no audio ? (Just for clarity, the HT does receive the
signal... just like there is noone talking - and yes the
volume is up. ).? I will try a few more things later this week
when my schedule allows for it.
Quite certain it is a 4100 problem, and not a QnetGateway
problem but I figured someone on this distribution list may
have ran into this problem before.
Thanks again for the suggestion.
Rob
On Wed, May 13, 2020 at 6:11
AM Tom Early < n7tae@...> wrote:
Make
sure your the offset is zero on your 4100. You'll have to get
out of AP mode because you can't set the offset while in that
modem.
After you return to normal mode, you shouldn't be in DR mode,
but your 4100 should display the frequency and indicate that
you are in DV mode. Then, enter the menu and select the top
menu item, "DUP/TONE", then select the Offset menu and set it
to zero.
|
Re: QnetGateway + ID-4100A in Access Point Mode + ID51A Plus
Hi Tom;
Thanks for the suggestion.? Unfortunately this did not change the behaviour. ??
Thinking it must be another setting on one of the radios I actually just did a factory reset on both the radios and still have the same behaviour once setting the frequencies, R1, R2, etc... ? I do find it odd that I do receive all the metadata? (I.e. the RX: line and the calls that are active) on the HT but just no audio ? (Just for clarity, the HT does receive the signal... just like there is noone talking - and yes the volume is up. ).? I will try a few more things later this week when my schedule allows for it.
Quite certain it is a 4100 problem, and not a QnetGateway problem but I figured someone on this distribution list may have ran into this problem before.
Thanks again for the suggestion.
Rob
On Wed, May 13, 2020 at 6:11 AM Tom Early < n7tae@...> wrote: Make sure your the offset is zero on your 4100. You'll have to get out of AP mode because you can't set the offset while in that modem.
After you return to normal mode, you shouldn't be in DR mode, but your 4100 should display the frequency and indicate that you are in DV mode. Then, enter the menu and select the top menu item, "DUP/TONE", then select the Offset menu and set it to zero.
|
Re: QnetGateway + ID-4100A in Access Point Mode + ID51A Plus
Make sure your the offset is zero on your 4100. You'll have to get out of AP mode because you can't set the offset while in that modem.
After you return to normal mode, you shouldn't be in DR mode, but your 4100 should display the frequency and indicate that you are in DV mode. Then, enter the menu and select the top menu item, "DUP/TONE", then select the Offset menu and set it to zero.
|
Elden AI7HL
Tom Early
