search

K3TZR / xSDR6000

Mac Client for the FlexRadio (TM) 6000 series software defined radios.
15 stars 2 forks source link

Frequency indication not updating if selected through other apps #4

Closed vu2cpl closed 3 years ago

vu2cpl commented 4 years ago

I am using xsdr6k with xCAT and xDAX and logging software is rumlogNG. while running WSJTX, if i select band from dropdown menu in WSJTX, the radio switches band, the display on rumlogNG as well as pan adapter shows correct band, but the label shows old band. this display gets updated the moment you try to tune even 1 Hz or if nothing is done, after a very long time. I am attaching a screenshot. You can see active frequency is 7074, but label shows 50.313 Mhz

Screenshot 2020-06-08 at 2 23 38 PM

K3TZR commented 4 years ago

Thank you for the report. It sounds like the display is not being redrawn when the external band change occurs. I’ll add it to my list of bugs to fix for the next version.

73’s Doug

On Jun 8, 2020, at 04:55, vu2cpl notifications@github.com wrote:

 I am using xsdr6k with xCAT and xDAX and logging software is rumlogNG. while running WSJTX, if i select band from dropdown menu in WSJTX, the radio switches band, the display on rumlogNG as well as pan adapter shows correct band, but the label shows old band. this display gets updated the moment you try to tune even 1 Hz or if nothing is done, after a very long time. I am attaching a screenshot. You can see active frequency is 7074, but label shows 50.313 Mhz

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

vu2cpl commented 4 years ago

Thank you Doug

73

Manoj VU2CPL

On 08-Jun-2020, at 3:48 PM, DougVB notifications@github.com wrote:

Thank you for the report. It sounds like the display is not being redrawn when the external band change occurs. I’ll add it to my list of bugs to fix for the next version.

73’s Doug

On Jun 8, 2020, at 04:55, vu2cpl notifications@github.com wrote:

 I am using xsdr6k with xCAT and xDAX and logging software is rumlogNG. while running WSJTX, if i select band from dropdown menu in WSJTX, the radio switches band, the display on rumlogNG as well as pan adapter shows correct band, but the label shows old band. this display gets updated the moment you try to tune even 1 Hz or if nothing is done, after a very long time. I am attaching a screenshot. You can see active frequency is 7074, but label shows 50.313 Mhz

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/K3TZR/xSDR6000/issues/4#issuecomment-640513026, or unsubscribe https://github.com/notifications/unsubscribe-auth/AP2WLB5J7K3DP5HDHXA4JLDRVS3I3ANCNFSM4NYFZ47Q.

K3TZR commented 4 years ago

Manoj,

I’ve investigated this issues and found the cause. It’s not a simple problem. Here’s what I found.

I was able to reproduce it here using xAPITester to send a change of frequency to xSDR6000. Apparently WSJTX does not send a “band” command but rather sends a “frequency” command.

When I look at what the Radio sends back when I change the frequency from 3.800 to 7.250 (filtering out anything that does not have the new frequency in it) this is what you get:

C955|slice tune 0 7.250 S65815B27|transmit freq=7.250000 lo=100 hi=2900 tx_filter_changes_allowed=1 S65815B27|display pan 0x40000000 center=7.250000 S65815B27|display waterfall 0x42000000 center=7.250000 S65815B27|transmit freq=7.250000 rfpower=100 tunepower=10 tx_slice_mode=LSB hwalc_enabled=0 inhibit=0 dax=0 sb_monitor=0 mon_gain_sb=80 mon_pan_sb=50 met_in_rx=0 am_carrier_level=100 mic_selection=MIC mic_level=40 mic_boost=1 mic_bias=1 mic_acc=0 compander=1 compander_level=70 vox_enable=0 vox_level=50 vox_delay=1261537088 speech_processor_enable=1 speech_processor_level=1 lo=100 hi=2900 tx_filter_changes_allowed=1 tx_antenna=ANT1 pitch=600 speed=30 iambic=1 iambic_mode=1 swap_paddles=0 break_in=1 break_in_delay=41 cwl_enabled=0 sidetone=1 mon_gain_cw=80 mon_pan_cw=50 synccwx=1

Notice that there is nothing to tell you that the Slice frequency changed!

It looks like FlexLib / SmartSDR handle this by using what FlexLib calls a reply handler. When the reply to the original command arrives (I suspect) they change the frequency in SmartSDR. I chose to use the Slice Status messages sent by the radio for things like this BUT in this case there is no Slice Status message sent that includes the new frequency. In my opinion, this is a mistake / inconsistency in the Flex TCP Protocol. There are actually eight “slice” messages in the reply from the radio (not shown here) but none of them contain the frequency (new or old).

I’ll fix this in the next version, probably by implementing a reply handler for this case.

Thank you for finding this and for documenting it in a very clear fashion.

73’s Doug - K3TZR

On Jun 8, 2020, at 6:20 AM, vu2cpl notifications@github.com wrote:

Thank you Doug

73

Manoj VU2CPL

vu2cpl commented 4 years ago

Thank you Doug for the detailed message. I am happy you could get to the bottom of this issue.

Will wait for the fix.

73

Manoj VU2CPL

Sent from my iPhone

On 10-Jun-2020, at 23:04, DougVB notifications@github.com wrote:

 Manoj,

I’ve investigated this issues and found the cause. It’s not a simple problem. Here’s what I found.

I was able to reproduce it here using xAPITester to send a change of frequency to xSDR6000. Apparently WSJTX does not send a “band” command but rather sends a “frequency” command.

When I look at what the Radio sends back when I change the frequency from 3.800 to 7.250 (filtering out anything that does not have the new frequency in it) this is what you get:

C955|slice tune 0 7.250 S65815B27|transmit freq=7.250000 lo=100 hi=2900 tx_filter_changes_allowed=1 S65815B27|display pan 0x40000000 center=7.250000 S65815B27|display waterfall 0x42000000 center=7.250000 S65815B27|transmit freq=7.250000 rfpower=100 tunepower=10 tx_slice_mode=LSB hwalc_enabled=0 inhibit=0 dax=0 sb_monitor=0 mon_gain_sb=80 mon_pan_sb=50 met_in_rx=0 am_carrier_level=100 mic_selection=MIC mic_level=40 mic_boost=1 mic_bias=1 mic_acc=0 compander=1 compander_level=70 vox_enable=0 vox_level=50 vox_delay=1261537088 speech_processor_enable=1 speech_processor_level=1 lo=100 hi=2900 tx_filter_changes_allowed=1 tx_antenna=ANT1 pitch=600 speed=30 iambic=1 iambic_mode=1 swap_paddles=0 break_in=1 break_in_delay=41 cwl_enabled=0 sidetone=1 mon_gain_cw=80 mon_pan_cw=50 synccwx=1

Notice that there is nothing to tell you that the Slice frequency changed!

It looks like FlexLib / SmartSDR handle this by using what FlexLib calls a reply handler. When the reply to the original command arrives (I suspect) they change the frequency in SmartSDR. I chose to use the Slice Status messages sent by the radio for things like this BUT in this case there is no Slice Status message sent that includes the new frequency. In my opinion, this is a mistake / inconsistency in the Flex TCP Protocol. There are actually eight “slice” messages in the reply from the radio (not shown here) but none of them contain the frequency (new or old).

I’ll fix this in the next version, probably by implementing a reply handler for this case.

Thank you for finding this and for documenting it in a very clear fashion.

73’s Doug - K3TZR

On Jun 8, 2020, at 6:20 AM, vu2cpl notifications@github.com wrote:

Thank you Doug

73

Manoj VU2CPL

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

K3TZR commented 4 years ago

Manoj,

Actually, I’m still working on this and I think my explanation was premature. It’s more complicated than I thought and I think it’s my issue not the Flex protocol.

I’ll update you once I fix this.

73’s Doug - K3TZR

On Jun 10, 2020, at 9:47 PM, vu2cpl notifications@github.com wrote:

Thank you Doug for the detailed message. I am happy you could get to the bottom of this issue.

Will wait for the fix.

73

Manoj VU2CPL

Sent from my iPhone

On 10-Jun-2020, at 23:04, DougVB notifications@github.com wrote:

 Manoj,

I’ve investigated this issues and found the cause. It’s not a simple problem. Here’s what I found.

I was able to reproduce it here using xAPITester to send a change of frequency to xSDR6000. Apparently WSJTX does not send a “band” command but rather sends a “frequency” command.

When I look at what the Radio sends back when I change the frequency from 3.800 to 7.250 (filtering out anything that does not have the new frequency in it) this is what you get:

C955|slice tune 0 7.250 S65815B27|transmit freq=7.250000 lo=100 hi=2900 tx_filter_changes_allowed=1 S65815B27|display pan 0x40000000 center=7.250000 S65815B27|display waterfall 0x42000000 center=7.250000 S65815B27|transmit freq=7.250000 rfpower=100 tunepower=10 tx_slice_mode=LSB hwalc_enabled=0 inhibit=0 dax=0 sb_monitor=0 mon_gain_sb=80 mon_pan_sb=50 met_in_rx=0 am_carrier_level=100 mic_selection=MIC mic_level=40 mic_boost=1 mic_bias=1 mic_acc=0 compander=1 compander_level=70 vox_enable=0 vox_level=50 vox_delay=1261537088 speech_processor_enable=1 speech_processor_level=1 lo=100 hi=2900 tx_filter_changes_allowed=1 tx_antenna=ANT1 pitch=600 speed=30 iambic=1 iambic_mode=1 swap_paddles=0 break_in=1 break_in_delay=41 cwl_enabled=0 sidetone=1 mon_gain_cw=80 mon_pan_cw=50 synccwx=1

Notice that there is nothing to tell you that the Slice frequency changed!

It looks like FlexLib / SmartSDR handle this by using what FlexLib calls a reply handler. When the reply to the original command arrives (I suspect) they change the frequency in SmartSDR. I chose to use the Slice Status messages sent by the radio for things like this BUT in this case there is no Slice Status message sent that includes the new frequency. In my opinion, this is a mistake / inconsistency in the Flex TCP Protocol. There are actually eight “slice” messages in the reply from the radio (not shown here) but none of them contain the frequency (new or old).

I’ll fix this in the next version, probably by implementing a reply handler for this case.

Thank you for finding this and for documenting it in a very clear fashion.

73’s Doug - K3TZR

On Jun 8, 2020, at 6:20 AM, vu2cpl notifications@github.com wrote:

Thank you Doug

73

Manoj VU2CPL

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe. — You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/K3TZR/xSDR6000/issues/4#issuecomment-642356204, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOCCVKDO2WCYCBL2BT3B243RWAZUXANCNFSM4NYFZ47Q.

vu2cpl commented 4 years ago

Ok Doug,

I am using it as it is and can wait for the fix when it’s available.

Thank you for your hard work!

73

Manoj VU2CPL

Sent from my iPhone

On 11-Jun-2020, at 07:21, DougVB notifications@github.com wrote:

 Manoj,

Actually, I’m still working on this and I think my explanation was premature. It’s more complicated than I thought and I think it’s my issue not the Flex protocol.

I’ll update you once I fix this.

73’s Doug - K3TZR

On Jun 10, 2020, at 9:47 PM, vu2cpl notifications@github.com wrote:

Thank you Doug for the detailed message. I am happy you could get to the bottom of this issue.

Will wait for the fix.

73

Manoj VU2CPL

Sent from my iPhone

On 10-Jun-2020, at 23:04, DougVB notifications@github.com wrote:

 Manoj,

I’ve investigated this issues and found the cause. It’s not a simple problem. Here’s what I found.

I was able to reproduce it here using xAPITester to send a change of frequency to xSDR6000. Apparently WSJTX does not send a “band” command but rather sends a “frequency” command.

When I look at what the Radio sends back when I change the frequency from 3.800 to 7.250 (filtering out anything that does not have the new frequency in it) this is what you get:

C955|slice tune 0 7.250 S65815B27|transmit freq=7.250000 lo=100 hi=2900 tx_filter_changes_allowed=1 S65815B27|display pan 0x40000000 center=7.250000 S65815B27|display waterfall 0x42000000 center=7.250000 S65815B27|transmit freq=7.250000 rfpower=100 tunepower=10 tx_slice_mode=LSB hwalc_enabled=0 inhibit=0 dax=0 sb_monitor=0 mon_gain_sb=80 mon_pan_sb=50 met_in_rx=0 am_carrier_level=100 mic_selection=MIC mic_level=40 mic_boost=1 mic_bias=1 mic_acc=0 compander=1 compander_level=70 vox_enable=0 vox_level=50 vox_delay=1261537088 speech_processor_enable=1 speech_processor_level=1 lo=100 hi=2900 tx_filter_changes_allowed=1 tx_antenna=ANT1 pitch=600 speed=30 iambic=1 iambic_mode=1 swap_paddles=0 break_in=1 break_in_delay=41 cwl_enabled=0 sidetone=1 mon_gain_cw=80 mon_pan_cw=50 synccwx=1

Notice that there is nothing to tell you that the Slice frequency changed!

It looks like FlexLib / SmartSDR handle this by using what FlexLib calls a reply handler. When the reply to the original command arrives (I suspect) they change the frequency in SmartSDR. I chose to use the Slice Status messages sent by the radio for things like this BUT in this case there is no Slice Status message sent that includes the new frequency. In my opinion, this is a mistake / inconsistency in the Flex TCP Protocol. There are actually eight “slice” messages in the reply from the radio (not shown here) but none of them contain the frequency (new or old).

I’ll fix this in the next version, probably by implementing a reply handler for this case.

Thank you for finding this and for documenting it in a very clear fashion.

73’s Doug - K3TZR

On Jun 8, 2020, at 6:20 AM, vu2cpl notifications@github.com wrote:

Thank you Doug

73

Manoj VU2CPL

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe. — You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/K3TZR/xSDR6000/issues/4#issuecomment-642356204, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOCCVKDO2WCYCBL2BT3B243RWAZUXANCNFSM4NYFZ47Q.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

K3TZR commented 4 years ago

Manoj,

The current release (v1.2.4) should fix the issue you reported. Please let me know if it does not.

73’s Doug - K3TZR

On Jun 10, 2020, at 9:54 PM, vu2cpl notifications@github.com wrote:

Ok Doug,

I am using it as it is and can wait for the fix when it’s available.

Thank you for your hard work!

73

Manoj VU2CPL

vu2cpl commented 4 years ago

Thank you Doug. Will check and revert. 73, Manoj VU2CPL

Sent from my iPhone

On 14-Jun-2020, at 01:01, DougVB notifications@github.com wrote:

 Manoj,

The current release (v1.2.4) should fix the issue you reported. Please let me know if it does not.

73’s Doug - K3TZR

On Jun 10, 2020, at 9:54 PM, vu2cpl notifications@github.com wrote:

Ok Doug,

I am using it as it is and can wait for the fix when it’s available.

Thank you for your hard work!

73

Manoj VU2CPL

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

vu2cpl commented 4 years ago

Thanks Doug, its fixed with 1.24.

73

Manoj VU2CPL

On 14-Jun-2020, at 1:01 AM, DougVB notifications@github.com wrote:

Manoj,

The current release (v1.2.4) should fix the issue you reported. Please let me know if it does not.

73’s Doug - K3TZR

On Jun 10, 2020, at 9:54 PM, vu2cpl notifications@github.com wrote:

Ok Doug,

I am using it as it is and can wait for the fix when it’s available.

Thank you for your hard work!

73

Manoj VU2CPL

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/K3TZR/xSDR6000/issues/4#issuecomment-643667696, or unsubscribe https://github.com/notifications/unsubscribe-auth/AP2WLBYMW5FZYLYHILGUBL3RWPHZZANCNFSM4NYFZ47Q.