Open plmathews opened 2 years ago
plmathews
commented
2 years ago I should add: The effect described in my post can be mitigated by the choice of a higher Sample Rate in Menu>Radio. At 48000 samples the effect is very pronounced but at 384000 samples the effect is not present. Sadly, in order to avoid unacceptable Sequence Errors it is necessary to use 48000 samples.
K7MDL2
commented
2 years ago I observed this also in the DL1YCF fork I am using (with the latest updates applied). In CW modes it does not happen for me. I am on a HL2.
I also observed the CW break-in (CW hang time) and CW_PTT_key_hang time variables do not appear to be used by the app though they are sent to the HL2 in old_protocol.c. Changing these values in the CW menu have no seeming effect. Maybe related to the post TX blurp.
Edit: I think the values are only used in the HL2 keyer/PTT physical input jack. The local MIDI keyer is responsible for PTT lead and trailing delays. For some reason for a time my HL2 was switching back to RX before the MIDI PTT arrived. I switched to the g0orx fork, updated it, and it has the same post-TX blurp, but the early RX switchover problem went away. It stayed away when I went back to the DL1YCF fork.
I modified the CW side tone to mute until my MIDI keyer changed PTT to Rx so the lack of TX blurp may be due to that for me. I note lots of effort in the CW code making the sidetone sound sample=0 (and RX sound I think is cut off while in TX) during transitions. I have not looked at the non-CW code to see if the same effort is applied.
dl1ycf
commented
2 years ago Just turn off "duplex".
plmathews
commented
2 years ago Sorry, this is not the cause of the problem. Duplex is and always has been switched off here. The easiest way to demonstrate this problem is to connect a dummy load to the aerial socket of your rig; then "press" the pihpsdr's TUNE button; then release the TUNE button; immediately pihpsdr switches from Transmit to Receive you will hear a few milliseconds of the tune signal at your audio out. Incidentally, in case you think that it might be faulty T>R switching external to the red pitaya/pihpsdr combo, the effect can be heard with nothing connected to the red pitaya except the raspberry pi running pihpsdr.
As I said before, this problem can be mitigated by increasing the Sample Rate. The duration of the residual audio decreases as the Sample Rate is increased until it is not discernible at 384000 samples. Sadly the Sequence Errors become unacceptable beyond 96000 samples.
Paul G4WJH
From: dl1ycf @.*** Sent: 29 December 2021 13:38 To: g0orx/pihpsdr Cc: plmathews; Author Subject: Re: [g0orx/pihpsdr] Residual TX audio heard on Transmit to Receive transition (Issue #164)
Just turn off "duplex".
— Reply to this email directly, view it on GitHub https://github.com/g0orx/pihpsdr/issues/164#issuecomment-1002598515 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AJEMWN7IGKFTE4K57HQEWT3UTMFKZANCNFSM5IYL5C4A . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub . You are receiving this because you authored the thread.Image removed by sender.Message ID: @.***>
http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient Image removed by sender.
Virus-free. http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient www.avg.com
dl1ycf
commented
2 years ago Oh I see. Even if you do not use duplex, the RX samples keep flowing from the radio and of course they have the TX signal on it (crosstalk from the T/R relay).
Even if you empty the buffer with the incoming samples upon TX/RX transition, there are possibly still samples left in the RX FIFO of the FPGA. Without duplex, the receivers are shut down upont RX/TX and then started again after TR/RX, so you should not see too much from those samples.
Note with my Anan running P1, I do not see these "Echos". Are you running P1 or P2 with your radio? Anyway, without duplex, no IQ samples arrive (receiver.c, function add_iq_samples()) during TX, so what you see comes from IQ samples that arrive after the TX/RX transition.
Are you able to do some basic programming? One possibility could be that upon a TX/RX transition, a global counter is set to, say, 1000, and then each incoming sample is processed with the following pseudo-code
if (counter > 0) { couter--; set all RX samples to zero; }
so this "mutes" the first 1000 incoming samples after RX/TX.
Do you want to perform experiments along this line? I cannot do it on my own since with my radio nothing happens.
Am 29.12.2021 um 18:22 schrieb plmathews @.***>:
Sorry, this is not the cause of the problem. Duplex is and always has been switched off here. The easiest way to demonstrate this problem is to connect a dummy load to the aerial socket of your rig; then "press" the pihpsdr's TUNE button; then release the TUNE button; immediately pihpsdr switches from Transmit to Receive you will hear a few milliseconds of the tune signal at your audio out. Incidentally, in case you think that it might be faulty T>R switching external to the red pitaya/pihpsdr combo, the effect can be heard with nothing connected to the red pitaya except the raspberry pi running pihpsdr.
As I said before, this problem can be mitigated by increasing the Sample Rate. The duration of the residual audio decreases as the Sample Rate is increased until it is not discernible at 384000 samples. Sadly the Sequence Errors become unacceptable beyond 96000 samples.
Paul G4WJH
From: dl1ycf @.*** Sent: 29 December 2021 13:38 To: g0orx/pihpsdr Cc: plmathews; Author Subject: Re: [g0orx/pihpsdr] Residual TX audio heard on Transmit to Receive transition (Issue #164)
Just turn off "duplex".
— Reply to this email directly, view it on GitHub https://github.com/g0orx/pihpsdr/issues/164#issuecomment-1002598515 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AJEMWN7IGKFTE4K57HQEWT3UTMFKZANCNFSM5IYL5C4A . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub . You are receiving this because you authored the thread.Image removed by sender.Message ID: @.***>
http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient Image removed by sender.
Virus-free. http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient www.avg.com
— Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you commented.
plmathews
commented
2 years ago Many thanks for your reply. Just to be clear, the effect is present when there is no physical "T/R relay" being used. My Pi is a Pi4 Model B with 8GB of RAM.
Yes, I would be very pleased to experiment because I really would like to resolve this problem. I have absolutely no programming expertise so I would need to be led by the hand through any experimental code changes.
From: dl1ycf @.*** Sent: 29 December 2021 17:40 To: g0orx/pihpsdr Cc: plmathews; Author Subject: Re: [g0orx/pihpsdr] Residual TX audio heard on Transmit to Receive transition (Issue #164)
Oh I see. Even if you do not use duplex, the RX samples keep flowing from the radio and of course they have the TX signal on it (crosstalk from the T/R relay).
Even if you empty the buffer with the incoming samples upon TX/RX transition, there are possibly still samples left in the RX FIFO of the FPGA. Without duplex, the receivers are shut down upont RX/TX and then started again after TR/RX, so you should not see too much from those samples.
Note with my Anan running P1, I do not see these "Echos". Are you running P1 or P2 with your radio? Anyway, without duplex, no IQ samples arrive (receiver.c, function add_iq_samples()) during TX, so what you see comes from IQ samples that arrive after the TX/RX transition.
Are you able to do some basic programming? One possibility could be that upon a TX/RX transition, a global counter is set to, say, 1000, and then each incoming sample is processed with the following pseudo-code
if (counter > 0) { couter--; set all RX samples to zero; }
so this "mutes" the first 1000 incoming samples after RX/TX.
Do you want to perform experiments along this line? I cannot do it on my own since with my radio nothing happens.
Am 29.12.2021 um 18:22 schrieb plmathews @.***>:
Sorry, this is not the cause of the problem. Duplex is and always has been switched off here. The easiest way to demonstrate this problem is to connect a dummy load to the aerial socket of your rig; then "press" the pihpsdr's TUNE button; then release the TUNE button; immediately pihpsdr switches from Transmit to Receive you will hear a few milliseconds of the tune signal at your audio out. Incidentally, in case you think that it might be faulty T>R switching external to the red pitaya/pihpsdr combo, the effect can be heard with nothing connected to the red pitaya except the raspberry pi running pihpsdr.
As I said before, this problem can be mitigated by increasing the Sample Rate. The duration of the residual audio decreases as the Sample Rate is increased until it is not discernible at 384000 samples. Sadly the Sequence Errors become unacceptable beyond 96000 samples.
Paul G4WJH
From: dl1ycf @.*** Sent: 29 December 2021 13:38 To: g0orx/pihpsdr Cc: plmathews; Author Subject: Re: [g0orx/pihpsdr] Residual TX audio heard on Transmit to Receive transition (Issue #164)
Just turn off "duplex".
— Reply to this email directly, view it on GitHub https://github.com/g0orx/pihpsdr/issues/164#issuecomment-1002598515 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AJEMWN7IGKFTE4K57HQEWT3UTMFKZANCNFSM5IYL5C4A . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub . You are receiving this because you authored the thread.Image removed by sender.Message ID: @.***>
http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient Image removed by sender.
Virus-free. http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient www.avg.com
— Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you commented.
— Reply to this email directly, view it on GitHub https://github.com/g0orx/pihpsdr/issues/164#issuecomment-1002705338 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AJEMWN77P2NHF54ICX77MDTUTNBY3ANCNFSM5IYL5C4A . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub . You are receiving this because you authored the thread.Image removed by sender.Message ID: @.***>
http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient Image removed by sender.
Virus-free. http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient www.avg.com
plmathews
commented
2 years ago PS Very sorry......I think you were asking me which protocol I was using. I'm using protocol 1. I think the red pitaya board is pretending to be a Hermes board.
From: Paul Mathews @.*** Sent: 29 December 2021 18:01 To: 'g0orx/pihpsdr'; 'g0orx/pihpsdr' Cc: 'Author' Subject: RE: [g0orx/pihpsdr] Residual TX audio heard on Transmit to Receive transition (Issue #164)
Many thanks for your reply. Just to be clear, the effect is present when there is no physical "T/R relay" being used. My Pi is a Pi4 Model B with 8GB of RAM.
Yes, I would be very pleased to experiment because I really would like to resolve this problem. I have absolutely no programming expertise so I would need to be led by the hand through any experimental code changes.
dl1ycf
commented
2 years ago If you see „tails“ of your TX signal in your RX, then somewhere there must be cross-talk. Perhaps you disclose your e-mail address directly to me @.***), this becomes too involved to do via the GitHub notifications.
Am 29.12.2021 um 19:01 schrieb plmathews @.***>:
Many thanks for your reply. Just to be clear, the effect is present when there is no physical "T/R relay" being used. My Pi is a Pi4 Model B with 8GB of RAM.
Yes, I would be very pleased to experiment because I really would like to resolve this problem. I have absolutely no programming expertise so I would need to be led by the hand through any experimental code changes.
From: dl1ycf @.*** Sent: 29 December 2021 17:40 To: g0orx/pihpsdr Cc: plmathews; Author Subject: Re: [g0orx/pihpsdr] Residual TX audio heard on Transmit to Receive transition (Issue #164)
Oh I see. Even if you do not use duplex, the RX samples keep flowing from the radio and of course they have the TX signal on it (crosstalk from the T/R relay).
Even if you empty the buffer with the incoming samples upon TX/RX transition, there are possibly still samples left in the RX FIFO of the FPGA. Without duplex, the receivers are shut down upont RX/TX and then started again after TR/RX, so you should not see too much from those samples.
Note with my Anan running P1, I do not see these "Echos". Are you running P1 or P2 with your radio? Anyway, without duplex, no IQ samples arrive (receiver.c, function add_iq_samples()) during TX, so what you see comes from IQ samples that arrive after the TX/RX transition.
Are you able to do some basic programming? One possibility could be that upon a TX/RX transition, a global counter is set to, say, 1000, and then each incoming sample is processed with the following pseudo-code
if (counter > 0) { couter--; set all RX samples to zero; }
so this "mutes" the first 1000 incoming samples after RX/TX.
Do you want to perform experiments along this line? I cannot do it on my own since with my radio nothing happens.
Am 29.12.2021 um 18:22 schrieb plmathews @.***>:
Sorry, this is not the cause of the problem. Duplex is and always has been switched off here. The easiest way to demonstrate this problem is to connect a dummy load to the aerial socket of your rig; then "press" the pihpsdr's TUNE button; then release the TUNE button; immediately pihpsdr switches from Transmit to Receive you will hear a few milliseconds of the tune signal at your audio out. Incidentally, in case you think that it might be faulty T>R switching external to the red pitaya/pihpsdr combo, the effect can be heard with nothing connected to the red pitaya except the raspberry pi running pihpsdr.
As I said before, this problem can be mitigated by increasing the Sample Rate. The duration of the residual audio decreases as the Sample Rate is increased until it is not discernible at 384000 samples. Sadly the Sequence Errors become unacceptable beyond 96000 samples.
Paul G4WJH
From: dl1ycf @.*** Sent: 29 December 2021 13:38 To: g0orx/pihpsdr Cc: plmathews; Author Subject: Re: [g0orx/pihpsdr] Residual TX audio heard on Transmit to Receive transition (Issue #164)
Just turn off "duplex".
— Reply to this email directly, view it on GitHub https://github.com/g0orx/pihpsdr/issues/164#issuecomment-1002598515 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AJEMWN7IGKFTE4K57HQEWT3UTMFKZANCNFSM5IYL5C4A . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub . You are receiving this because you authored the thread.Image removed by sender.Message ID: @.***>
http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient Image removed by sender.
Virus-free. http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient www.avg.com
— Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you commented.
— Reply to this email directly, view it on GitHub https://github.com/g0orx/pihpsdr/issues/164#issuecomment-1002705338 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AJEMWN77P2NHF54ICX77MDTUTNBY3ANCNFSM5IYL5C4A . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub . You are receiving this because you authored the thread.Image removed by sender.Message ID: @.***>
http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient Image removed by sender.
Virus-free. http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient www.avg.com
— Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you commented.
dl1ycf
commented
2 years ago I have a „Hamlab“ which is RedPitaya based, I could do tests there.
Am 29.12.2021 um 20:26 schrieb plmathews @.***>:
PS Very sorry......I think you were asking me which protocol I was using. I'm using protocol 1. I think the red pitaya board is pretending to be a Hermes board.
From: Paul Mathews @.*** Sent: 29 December 2021 18:01 To: 'g0orx/pihpsdr'; 'g0orx/pihpsdr' Cc: 'Author' Subject: RE: [g0orx/pihpsdr] Residual TX audio heard on Transmit to Receive transition (Issue #164)
Many thanks for your reply. Just to be clear, the effect is present when there is no physical "T/R relay" being used. My Pi is a Pi4 Model B with 8GB of RAM.
Yes, I would be very pleased to experiment because I really would like to resolve this problem. I have absolutely no programming expertise so I would need to be led by the hand through any experimental code changes.
— Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you commented.
plmathews
commented
2 years ago Dear Christoph,
Many thanks for taking an interest in my problem. It seems as though it may be unique to the red pitaya. My e-mail address is @.***
Kind regards
Paul
From: dl1ycf @.*** Sent: 30 December 2021 09:47 To: g0orx/pihpsdr Cc: plmathews; Author Subject: Re: [g0orx/pihpsdr] Residual TX audio heard on Transmit to Receive transition (Issue #164)
If you see „tails“ of your TX signal in your RX, then somewhere there must be cross-talk. Perhaps you disclose your e-mail address directly to me @.***), this becomes too involved to do via the GitHub notifications.
Am 29.12.2021 um 19:01 schrieb plmathews @.***>:
Many thanks for your reply. Just to be clear, the effect is present when there is no physical "T/R relay" being used. My Pi is a Pi4 Model B with 8GB of RAM.
Yes, I would be very pleased to experiment because I really would like to resolve this problem. I have absolutely no programming expertise so I would need to be led by the hand through any experimental code changes.
From: dl1ycf @.*** Sent: 29 December 2021 17:40 To: g0orx/pihpsdr Cc: plmathews; Author Subject: Re: [g0orx/pihpsdr] Residual TX audio heard on Transmit to Receive transition (Issue #164)
Oh I see. Even if you do not use duplex, the RX samples keep flowing from the radio and of course they have the TX signal on it (crosstalk from the T/R relay).
Even if you empty the buffer with the incoming samples upon TX/RX transition, there are possibly still samples left in the RX FIFO of the FPGA. Without duplex, the receivers are shut down upont RX/TX and then started again after TR/RX, so you should not see too much from those samples.
Note with my Anan running P1, I do not see these "Echos". Are you running P1 or P2 with your radio? Anyway, without duplex, no IQ samples arrive (receiver.c, function add_iq_samples()) during TX, so what you see comes from IQ samples that arrive after the TX/RX transition.
Are you able to do some basic programming? One possibility could be that upon a TX/RX transition, a global counter is set to, say, 1000, and then each incoming sample is processed with the following pseudo-code
if (counter > 0) { couter--; set all RX samples to zero; }
so this "mutes" the first 1000 incoming samples after RX/TX.
Do you want to perform experiments along this line? I cannot do it on my own since with my radio nothing happens.
Am 29.12.2021 um 18:22 schrieb plmathews @.***>:
Sorry, this is not the cause of the problem. Duplex is and always has been switched off here. The easiest way to demonstrate this problem is to connect a dummy load to the aerial socket of your rig; then "press" the pihpsdr's TUNE button; then release the TUNE button; immediately pihpsdr switches from Transmit to Receive you will hear a few milliseconds of the tune signal at your audio out. Incidentally, in case you think that it might be faulty T>R switching external to the red pitaya/pihpsdr combo, the effect can be heard with nothing connected to the red pitaya except the raspberry pi running pihpsdr.
As I said before, this problem can be mitigated by increasing the Sample Rate. The duration of the residual audio decreases as the Sample Rate is increased until it is not discernible at 384000 samples. Sadly the Sequence Errors become unacceptable beyond 96000 samples.
Paul G4WJH
From: dl1ycf @.*** Sent: 29 December 2021 13:38 To: g0orx/pihpsdr Cc: plmathews; Author Subject: Re: [g0orx/pihpsdr] Residual TX audio heard on Transmit to Receive transition (Issue #164)
Just turn off "duplex".
— Reply to this email directly, view it on GitHub https://github.com/g0orx/pihpsdr/issues/164#issuecomment-1002598515 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AJEMWN7IGKFTE4K57HQEWT3UTMFKZANCNFSM5IYL5C4A . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub . You are receiving this because you authored the thread.Image removed by sender.Message ID: @.***>
http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient Image removed by sender.
Virus-free. http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient www.avg.com
— Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you commented.
— Reply to this email directly, view it on GitHub https://github.com/g0orx/pihpsdr/issues/164#issuecomment-1002705338 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AJEMWN77P2NHF54ICX77MDTUTNBY3ANCNFSM5IYL5C4A . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub . You are receiving this because you authored the thread.Image removed by sender.Message ID: @.***>
http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient Image removed by sender.
Virus-free. http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient www.avg.com
— Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you commented.
— Reply to this email directly, view it on GitHub https://github.com/g0orx/pihpsdr/issues/164#issuecomment-1002950812 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AJEMWN4XWVR75MICSYXQKLTUTQTBRANCNFSM5IYL5C4A . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub . You are receiving this because you authored the thread.Image removed by sender.Message ID: @.***>
http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient Image removed by sender.
Virus-free. http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient www.avg.com
dl1ycf
commented
2 years ago Am 30.12.2021 um 11:54 schrieb plmathews @.***>:
Dear Christoph,
Many thanks for taking an interest in my problem. It seems as though it may be unique to the red pitaya. My e-mail address is @.***
email me direcly. Your address is suppressed if the message is sent via github.
dl1ycf
commented
2 years ago Dear Paul,
I can reproduce your problem also with my HermesLite-2.
Since I still do not have your email, I added some test code to my pihpsdr repo
github.com/dl1ycf/pihpsdr
(in github.com/dl1ycf/pihpsdr-compile-from-sources you find detailed instructions how to download and install). Alternatively, send email to @.*** to provide instructions to you directly how to modify the files you have (radio.c, receiver.h, receiver.c)
After compilation, start piHPSDR, attach dummy load and engage/disengage "TUNE" serveral times. After each TX/RX transition, you find on the screen (or the log file) and analysis how many "residual IQ samples" have been seen.
The diagnostic code can be removed later, you should already see the improvement quite clearly. Currently, I "silence" the first 31 msec of IQ data arriving after TX/RX. On the long run, this must be modified as
since in CW, there is no residual audio (due to hang time) and you want the fastest turnaround.
FYI, what is relevant are lines like this:
ID=0 MAXCOUNT=375
which indicate the length of the "TX tail" in samples encountered. For the HL2 MAXCOUNT goes up to 1500 or so, it might be different for the HAMlab.
Yours,
Christoph
plmathews
commented
2 years ago Dear Christoph,
This is all great news, thank you very much. I'm so sorry that I have failed to get my e-mail address to you - I've tried all of the e-mail addresses that appear here when you send me an e-mail. How can I get my e-mail address to you please?
I'll write again when I've found and tried your test code.
With thanks and wishing you a happy new year
Paul
From: dl1ycf @.*** Sent: 04 January 2022 13:27 To: g0orx/pihpsdr Cc: plmathews; Author Subject: Re: [g0orx/pihpsdr] Residual TX audio heard on Transmit to Receive transition (Issue #164)
Dear Paul,
I can reproduce your problem also with my HermesLite-2.
Since I still do not have your email, I added some test code to my pihpsdr repo
github.com/dl1ycf/pihpsdr
(in github.com/dl1ycf/pihpsdr-compile-from-sources you find detailed instructions how to download and install). Alternatively, send email to @.*** to provide instructions to you directly how to modify the files you have (radio.c, receiver.h, receiver.c)
After compilation, start piHPSDR, attach dummy load and engage/disengage "TUNE" serveral times. After each TX/RX transition, you find on the screen (or the log file) and analysis how many "residual IQ samples" have been seen.
The diagnostic code can be removed later, you should already see the improvement quite clearly. Currently, I "silence" the first 31 msec of IQ data arriving after TX/RX. On the long run, this must be modified as
since in CW, there is no residual audio (due to hang time) and you want the fastest turnaround.
FYI, what is relevant are lines like this:
ID=0 MAXCOUNT=375
which indicate the length of the "TX tail" in samples encountered. For the HL2 MAXCOUNT goes up to 1500 or so, it might be different for the HAMlab.
Yours,
Christoph
— Reply to this email directly, view it on GitHub https://github.com/g0orx/pihpsdr/issues/164#issuecomment-1004810354 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AJEMWN5XBNKA6P5XD733MDDUULYRPANCNFSM5IYL5C4A . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub . You are receiving this because you authored the thread.Image removed by sender.Message ID: @.***>
http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient Image removed by sender.
Virus-free. http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient www.avg.com
dl1ycf
commented
2 years ago You simply send me an email, it is
dl1ycf AT darc DOT de
when you send via github, you have to "hide" email addresses in the text otherwise they will be anonymized.
Am 04.01.2022 um 14:47 schrieb plmathews @.***>:
Dear Christoph,
This is all great news, thank you very much. I'm so sorry that I have failed to get my e-mail address to you - I've tried all of the e-mail addresses that appear here when you send me an e-mail. How can I get my e-mail address to you please?
I'll write again when I've found and tried your test code.
With thanks and wishing you a happy new year
Paul
From: dl1ycf @.*** Sent: 04 January 2022 13:27 To: g0orx/pihpsdr Cc: plmathews; Author Subject: Re: [g0orx/pihpsdr] Residual TX audio heard on Transmit to Receive transition (Issue #164)
Dear Paul,
I can reproduce your problem also with my HermesLite-2.
Since I still do not have your email, I added some test code to my pihpsdr repo
github.com/dl1ycf/pihpsdr
(in github.com/dl1ycf/pihpsdr-compile-from-sources you find detailed instructions how to download and install). Alternatively, send email to @.*** to provide instructions to you directly how to modify the files you have (radio.c, receiver.h, receiver.c)
After compilation, start piHPSDR, attach dummy load and engage/disengage "TUNE" serveral times. After each TX/RX transition, you find on the screen (or the log file) and analysis how many "residual IQ samples" have been seen.
The diagnostic code can be removed later, you should already see the improvement quite clearly. Currently, I "silence" the first 31 msec of IQ data arriving after TX/RX. On the long run, this must be modified as
- TUNE TX/RX: longest time
- SSB TX/RX: medium time
- CW TX/RX: don't silence anything
since in CW, there is no residual audio (due to hang time) and you want the fastest turnaround.
FYI, what is relevant are lines like this:
ID=0 MAXCOUNT=375
which indicate the length of the "TX tail" in samples encountered. For the HL2 MAXCOUNT goes up to 1500 or so, it might be different for the HAMlab.
Yours,
Christoph
— Reply to this email directly, view it on GitHub https://github.com/g0orx/pihpsdr/issues/164#issuecomment-1004810354 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AJEMWN5XBNKA6P5XD733MDDUULYRPANCNFSM5IYL5C4A . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub . You are receiving this because you authored the thread.Image removed by sender.Message ID: @.***>
http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient Image removed by sender.
Virus-free. http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient www.avg.com
— Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you commented.
dl1ycf
commented
2 years ago I have meanwhile tried three SDR's:
HAMlab/STEMlab : residual TX signal problem seen HermesLite-II: residual TX signal problem seen Anan-7000 problem not there!
"not there" means that the number of incoming "residual" samples is so small that "it" happens well withing the RX slew-up time, so no discernible problem.
I have now completed the coding, the new feature is only active on HermesLite-2 and STEMlab, and the "suppressed samples" are 31 msec for TUNE, AM, FM, no suppression for CW, and 16 msec for all other modes.
NOT YET pushed, please try out my first version (with the diagnostic output) first.
Yours, Christoph DL1YCF.
plmathews
commented
2 years ago I've sent you a couple of e-mails to the address you gave me Christoph. I wonder if they have arrived safely please? Paul
From: dl1ycf @.*** Sent: 04 January 2022 15:17 To: g0orx/pihpsdr Cc: plmathews; Author Subject: Re: [g0orx/pihpsdr] Residual TX audio heard on Transmit to Receive transition (Issue #164)
I have meanwhile tried three SDR's:
HAMlab/STEMlab : residual TX signal problem seen HermesLite-II: residual TX signal problem seen Anan-7000 problem not there!
"not there" means that the number of incoming "residual" samples is so small that "it" happens well withing the RX slew-up time, so no discernible problem.
I have now completed the coding, the new feature is only active on HermesLite-2 and STEMlab, and the "suppressed samples" are 31 msec for TUNE, AM, FM, no suppression for CW, and 16 msec for all other modes.
NOT YET pushed, please try out my first version (with the diagnostic output) first.
Yours, Christoph DL1YCF.
— Reply to this email directly, view it on GitHub https://github.com/g0orx/pihpsdr/issues/164#issuecomment-1004897160 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AJEMWN2GN2DO2JFQTRCUU4LUUMFNXANCNFSM5IYL5C4A . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub . You are receiving this because you authored the thread.Image removed by sender.Message ID: @.***>
http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient Image removed by sender.
Virus-free. http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient www.avg.com
dl1ycf
commented
2 years ago I have now completed an update, it is alreay in the DL1YCF repository and will be suggested "fast track" as a pull request as soon as the present (pending) one has been processed. From my viewpoint, this closes this discussion.
On the transition from TX to RX the last 200 milliseconds or so of the TX can be heard. Could this be due to the latency of the TX path and the TX to RX switch taking place before the TX is finished? I don't know whether this issue is unique to the Red Pitaya/PIHPSDR setup or whether it is a more general issue.