apache-labs.com

vk1hx wrote:

ramdor wrote:UPDATE

Hi all,

Just a couple of updates for (10/7/19) d3.

Please try : https://www.dropbox.com/s/pwx1eo4q5og6y ... 3.zip?dl=0

I have included a few dll's for completeness this time.

Thank you.

Running the latest updates. Not sure if it is an issue? when keying TX (MOX or PTT) I get a very quick sort of spectrum flash / jump / peak? hard to explain. Might be just a setting. I'll try and video record what its doing.

somehow I'm having trouble uploading attachments

Running the latest updates. Not sure if it is an issue? when keying TX (MOX or PTT) I get a very quick sort of spectrum flash / jump / peak? hard to explain. Might be just a setting. I'll try and video record what its doing.

This is because drawing thread is now not blocked, and the data arrays for what to draw changes, so you get to see the transition. I was contemplating resetting them on tx/rx but left as was.

Richie.

ramdor wrote:

This is because drawing thread is now not blocked, and the data arrays for what to draw changes, so you get to see the transition. I was contemplating resetting them on tx/rx but left as was.

Richie.

Copy. Thank for the explanation.

ramdor wrote:

Running the latest updates. Not sure if it is an issue? when keying TX (MOX or PTT) I get a very quick sort of spectrum flash / jump / peak? hard to explain. Might be just a setting. I'll try and video record what its doing.

This is because drawing thread is now not blocked, and the data arrays for what to draw changes, so you get to see the transition. I was contemplating resetting them on tx/rx but left as was.

Richie.

Richie... When unkeying mic I see what appears to be a momentary energy spike that peaks on the selected frequency and is the width of the panafall. Is there any correlation to this and what you just described? Is there a way to eliminate it? Very disconcerting to see. This is nothing new though.
FYI..... Since deselecting Network Watchdog I have not had a single disconnect in two days. Not a long time but encouraging.

Thx
Carl

Hi All,

Network-Dog is all the time on, but I have all Energie-Managment for my NIC disabled, it runs at full power, only 1 Gig no throttle,
all Energie-Saving disabled.
May be thats better???

73 Erwin

cLicari wrote:
Richie... When unkeying mic I see what appears to be a momentary energy spike that peaks on the selected frequency and is the width of the panafall. Is there any correlation to this and what you just described? Is there a way to eliminate it? Very disconcerting to see. This is nothing new though.
FYI..... Since deselecting Network Watchdog I have not had a single disconnect in two days. Not a long time but encouraging.

Thx
Carl

yes, we wouldn't have seen it before because the draw thread was stopped for at least rf_delay milliseconds. At least a couple of frames in most cases, which would be enough to not notice it. I will look to see if there is something obvious in the front end. However, it is more than likely coming out of WDSP.GetPixels which honestly I dont want to start messing with because it is hella scary in there and on a different level of awesome compared to the safety/simplicity of the front end code

Edit:
ok after looking into it, the issue probably arises because when we MOX we instantly start drawing TX buffers, however, the radio might not yet be in tx state, due to rf_delay. If you set this option to 0 in settings then the pulse vanishes, but it is not really the correct solution. I will do something about it. Previously it wouldn't have mattered, because whole drawing thread was blocked.

Cheers,

Richie.

Feature request to to add to the list Make turning on Spots easier than the multi step process it is today.

NC3Z wrote:Feature request to to add to the list Make turning on Spots easier than the multi step process it is today.

spot system needs a whole re-work, but everything is slowly turning into a massive exercise

Just realised, that even if PS is disabled, two timers tick away every 10ms and 100ms, the first setting a whole bunch of controls colours and what not 100 times a second, the other forcing TX attenuate on (if PS autoattenuate is ticked) even though PS is disabled................

Richie.

Why anyone would want to turn off PS is beyond me, unless you want to broaden your shoulders out if folks move in to close to you!

ramdor wrote:

cLicari wrote:
Richie... When unkeying mic I see what appears to be a momentary energy spike that peaks on the selected frequency and is the width of the panafall. Is there any correlation to this and what you just described? Is there a way to eliminate it? Very disconcerting to see. This is nothing new though.
FYI..... Since deselecting Network Watchdog I have not had a single disconnect in two days. Not a long time but encouraging.

Thx
Carl

yes, we wouldn't have seen it before because the draw thread was stopped for at least rf_delay milliseconds. At least a couple of frames in most cases, which would be enough to not notice it. I will look to see if there is something obvious in the front end. However, it is more than likely coming out of WDSP.GetPixels which honestly I dont want to start messing with because it is hella scary in there and on a different level of awesome compared to the safety/simplicity of the front end code

Edit:
ok after looking into it, the issue probably arises because when we MOX we instantly start drawing TX buffers, however, the radio might not yet be in tx state, due to rf_delay. If you set this option to 0 in settings then the pulse vanishes, but it is not really the correct solution. I will do something about it. Previously it wouldn't have mattered, because whole drawing thread was blocked.

Cheers,

Richie.

Richie...

Even with RF Delay set to 0 I still see the spike. The only way I have found to not see the spike, and this isn't a solution, is to deselect the "MIC" button before unkeying.

Thx
Carl

cLicari wrote:
Richie...

Even with RF Delay set to 0 I still see the spike. The only way I have found to not see the spike, and this isn't a solution, is to deselect the "MIC" button before unkeying.

Thx
Carl

try adding a bunch of RX delay, say 300ms, see if it vanishes. If you are seeing it after releasing mox then either RX delay, or MOX delay might do it. Not a solution really, but will have to find out where it is coming from first.

Richie.

ramdor wrote:

cLicari wrote:
Richie...

Even with RF Delay set to 0 I still see the spike. The only way I have found to not see the spike, and this isn't a solution, is to deselect the "MIC" button before unkeying.

Thx
Carl

try adding a bunch of RX delay, say 300ms, see if it vanishes. If you are seeing it after releasing mox then either RX delay, or MOX delay might do it. Not a solution really, but will have to find out where it is coming from first.

Richie.

Richie...

Added 100, 200 then 300ms of delay. No change
Carl

Hi Richie,

The wdsp flushChannel thread runs on each and every rx/tx and tx/rx transition. I wonder if you're "bumping heads" with that somehow?

73, Bryan W4WMT

Some care should be taken to not accidentally increase RX-TX-RX latency, which Warren and Chris worked VERY hard to minimize in Thetis 2.6.7. I have more design data on this to send, but am away from a real computer for the next few days and probably won't be able to until the weekend. It is suggested that if there has to be a purely visual artifact to support the very low latency that is a small price to pay.

Thanks,

Scott

Bryan W4WMT wrote:Hi Richie,

The wdsp flushChannel thread runs on each and every rx/tx and tx/rx transition. I wonder if you're "bumping heads" with that somehow?

73, Bryan W4WMT

Quite probably. For example, when going from rx to tx, It seems that GetPixels on the transition returns data that holds old rx info and is slowly changed, especially noticeable if fft bin width is very small. Seems like something is not cleared down. I dare not go fiddling around in there though

Richie.

This error is a new one on me. First image is the crash. Second image is when I tried to restart Thetis.

Edit: So it would appear the ANAN is locked up on the network. I can see the Ethernet activity light is still active even though thetis is closed. Also Thetis is crashing on TX.

I found the cause of the issue and Thetis crashing on TX.

If you unchecked the CW Break-In and Disable UI MOX Changes boxes outlined in red in the below picture this causes Thetis to crash on TX. I must have unchecked them at some point...

Anyway! back to normal....

I'm not a CW guy but I have played around with it the past few days. For what its worth Richie, I run a 8000DLE with a late serial number and I don't see this issue. Matter of fact it's been rock solid so far. I know NC3Z and NJ2US have been having problems with PS dropping and then coming back. From what I know there is no pattern but I'm sure they will chime in.

Again Richie, you are doing fantastic work and you're a asset to this platform.

vk1hk wrote:I found the cause of the issue and Thetis crashing on TX.

If you unchecked the CW Break-In and Disable UI MOX Changes boxes outlined in red in the below picture this causes Thetis to crash on TX. I must have unchecked them at some point...

Thanks, I have found the issue. The code tried to disable all MODE buttons in the mode group panel, however, I think an old test button was left in there called buttonTS1, the code behind the button had been commented out, but the button not removed. The code that disables the mode buttons assumes everything inside that panel is a radio button, which buttonTS1 is not, so boom.

w2ner wrote:Again Richie, you are doing fantastic work and you're a asset to this platform.

cheers Nicholas, but nothing compared to all the work done by others, i'm just playing about really

73 Richie.

Hi Richie,

I can easily crash Thetis D3 - without any failure message - by transmitting some CAT commands (DDUtil macros).

I use some macros to change the vertical scale manually on different bands. Thetis disappears if I click a few of the buttons very quick.

For VHF:
ZZDP-070;ZZDQ-165;
ZZDP-070;ZZDQ-160;
ZZDP-070;ZZDQ-155;

For HF:
ZZDP-040;ZZDQ-130;
ZZDP-040;ZZDQ-140;
ZZDP-040;ZZDQ-150;
ZZDP-040;ZZDQ-160;

DL8LAQ wrote:Hi Richie,

I can easily crash Thetis D3 - without any failure message - by transmitting some CAT commands (DDUtil macros).

I can not get this to happen here, I used your 4 HF cat commands, assigned them to buttons 1 through 4, and mashed F1-F4 and clicked as fast as possible in DDUtil and Thetis tracked the changes no problem. However, DDUtil showed problems, more than 1 button was highlighted, and it all froze up I guess with all the serial data going on. 9600 baud used.

As an aside, if there are any un-trapped crashes in Thetis, you will always get a detailed exception message, as there is a try/catch around the primary object. Also, if ever the main window closes you will always see shutdown splash. Even a windows shutdown (WM_QUERYENDSESSION) will cause thetis to close and result in splash and everything saved out (although you might not see it).

Richie.

cLicari wrote:

ramdor wrote:

cLicari wrote:
Richie...

Even with RF Delay set to 0 I still see the spike. The only way I have found to not see the spike, and this isn't a solution, is to deselect the "MIC" button before unkeying.

Thx
Carl

try adding a bunch of RX delay, say 300ms, see if it vanishes. If you are seeing it after releasing mox then either RX delay, or MOX delay might do it. Not a solution really, but will have to find out where it is coming from first.

Richie.

Richie...

Added 100, 200 then 300ms of delay. No change
Carl

Richie...
After deselecting Network Watchdog Thetis ran perfectly, for extended periods, some unattended to test it, for three days! After trying the RF Delays noted above I shut down for the evening, but forgot to return the RF Delay setting value back to 30. Later that night I turned the radio back on and Thetis would not connect after several attempts and was getting a dialog box "No Network Connection. Is it connected and powered" . I checked settings and realized I forgot to return RF Delay value to 30, and did so. I rebooted and Thetis connected but I soon started seeing "seq 41" errors and Thetis would crash in way I've never seen before, not just disconnect. Half of the waterfall display would quit and then Thetis would lock up with the panadapter display signals slowly bleeding down to flatline. I tried several more times with similar results. I tried importing a known good database, no help. At this point I have returned to P1 just so I can operate. Almost didn't even want to report this to the group it being so bizarre, but felt I really should.

Carl

cLicari wrote:Richie...
After deselecting Network Watchdog Thetis ran perfectly, for extended periods, some unattended to test it, for three days! After trying the RF Delays noted above I shut down for the evening, but forgot to return the RF Delay setting value back to 30. Later that night I turned the radio back on and Thetis would not connect after several attempts and was getting a dialog box "No Network Connection. Is it connected and powered" . I checked settings and realized I forgot to return RF Delay value to 30, and did so. I rebooted and Thetis connected but I soon started seeing "seq 41" errors and Thetis would crash in way I've never seen before, not just disconnect. Half of the waterfall display would quit and then Thetis would lock up with the panadapter display signals slowly bleeding down to flatline. I tried several more times with similar results. I tried importing a known good database, no help. At this point I have returned to P1 just so I can operate. Almost didn't even want to report this to the group it being so bizarre, but felt I really should.

Carl

I have a feeling that either you have a network/hardware issue with your computer/network, or there are some odd timing issues with your radio which show up when it is cold? (ie you just turned it on). The reason I say this is that if it was a problem in Thetis, everyone would be reporting it. Don't get hung up on the rf_delay setting that just adds a small sleep delay during mox tx.

I don't know your network setup there, but perhaps borrow/use a laptop, direct connection to radio and try that, just to eliminate everything else.

edit: one of two issues perhaps a) timing issue with radio HW..... b) problem with something on your network when running at 1gbit

Richie.

hi All,
i wrote this again,
my anan is connected with a seperate nic, an i have disablad all energie option and shut down do another network as 1 gb for all time,
i have no problems here, my by this is a problem with the windows energie managment ???

edit: i run thetis 2.6.8 d3, its running perfect here! Many, very many thanks to richie !!

ramdor wrote:

cLicari wrote:Richie...
After deselecting Network Watchdog Thetis ran perfectly, for extended periods, some unattended to test it, for three days! After trying the RF Delays noted above I shut down for the evening, but forgot to return the RF Delay setting value back to 30. Later that night I turned the radio back on and Thetis would not connect after several attempts and was getting a dialog box "No Network Connection. Is it connected and powered" . I checked settings and realized I forgot to return RF Delay value to 30, and did so. I rebooted and Thetis connected but I soon started seeing "seq 41" errors and Thetis would crash in way I've never seen before, not just disconnect. Half of the waterfall display would quit and then Thetis would lock up with the panadapter display signals slowly bleeding down to flatline. I tried several more times with similar results. I tried importing a known good database, no help. At this point I have returned to P1 just so I can operate. Almost didn't even want to report this to the group it being so bizarre, but felt I really should.

Carl

I have a feeling that either you have a network/hardware issue with your computer/network, or there are some odd timing issues with your radio which show up when it is cold? (ie you just turned it on). The reason I say this is that if it was a problem in Thetis, everyone would be reporting it. Don't get hung up on the rf_delay setting that just adds a small sleep delay during mox tx.

I don't know your network setup there, but perhaps borrow/use a laptop, direct connection to radio and try that, just to eliminate everything else.

Richie.

The Anan is on a dedicated subnet direct to the computer. I installed a new Intel NIC last week replacing a Realtek. P1 works without issue and always has. Possibly a timing issue. Past problems have occurred later rather than earlier in an operating session. The RF Delay thing was the only change, of any kind, I had made after the rig running solid for three previous day. Coincidence, probably, but I had to throw it out there. I'll check the energy management settings. Seems to be just another case of "your results may vary".
Thx
Carl

ramdor wrote:I can not get this to happen here, I used your 4 HF cat commands, assigned them to buttons 1 through 4, and mashed F1-F4 and clicked as fast as possible in DDUtil and Thetis tracked the changes no problem. However, DDUtil showed problems, more than 1 button was highlighted, and it all froze up I guess with all the serial data going on. 9600 baud used.

As an aside, if there are any un-trapped crashes in Thetis, you will always get a detailed exception message, as there is a try/catch around the primary object. Also, if ever the main window closes you will always see shutdown splash. Even a windows shutdown (WM_QUERYENDSESSION) will cause thetis to close and result in splash and everything saved out (although you might not see it).

Thank for info. This is really interesting.

UPDATE

Hi all,

Please try : https://www.dropbox.com/s/zgrf98a8eaf5g ... l.zip?dl=0

I have changed the state/options save code (not tx profile etc) to use a primary key in the database. For this reason, please take a backup of your database and archive it away. The main result is that saving is nearly instant now, instead of 7-12 seconds. Consequently shut down of Thetis is very fast and the shutdown splash has barely any time to display .

As always, full change log here, including known issues : https://docs.google.com/document/d/1xh4 ... 5-ibeIBt_k

73 Richie.

(10/7/19) d4

• fix: vertical text padding on spectrum grid now spaces correctly in DX mode
• fix: null audio phase buffer would cause crash for phase2 (not that phase2 does anything atm)
• change: ok/cancel/apply buttons on setup form become disabled if a save/load is in progress. Crossing of the setup window does nothing but hide it. Cancel will reload DB and close form, OK will update internal settings only and not save out xml file. Apply does the same but also updates xml file. Xml file written out when Theits shuts down. All of this behaviour is existing, except for the enable/disable of buttons and a small label to show activity. Even changing Region will cause an update to the DB + xml file. Saving the state of over 1800 controls is a slow process, upwards of 7 seconds. (now a non issue due to change to SaveVars below)
• fix: PS form does not set attenuate tx setting unless it needs to. Previously it was setting it even if attenuation changes were not being made, 10 times a second
• add: spectrum scale numbers now highlight when hovering over with mouse (DirectX only)
• change: grid/overlays are done after panadaptor plot, previously they were done before and would sometimes be obscured
• fix: crash issue reported by vk1hk when disable_ui_mox_changes was unchecked and mox pressed
• change: on exit we join any existing save thread and wait for it to happen, then perform final save
• fix: changing setup max/min spectrum will update the waterfall range if sync waterfall is selected
• change: Database.SaveVars now uses Table.Rows.Find and associated primary key instead of Table.Select. Speed of saving database settings is vastly improved

Thanks Richie , just installed. Like the messages on start up and the lightning quick shut down

Richie,

I'll echo Tony's report, the loading form messages are a nice touch and the nearly instant exit is great. I'll be very interested in the change to the PS auto-attenuate sampling interval. Perhaps the "as needed" approach will mitigate the tendency for PS to suddenly stop working here and there? The spectrum scale highlighting is excellent!

Thanks for the look at the D4 changes.

73,

Rob W1AEX