|
What to do with it? First i thought, that it is software problem with PLL, but it looks OK.
Somebody resolved problem?
MAc sp9mrn
|
I assume you are talking about the Raduino clicking as you tune. I'm not having that problem, but others are. One solution is to bypass both the input and output of the 7805 regulator with some 100nf caps. Apparently not all of the Arduino Nano clones are from the same manufacturer and some have better bypassing onboard than others, so all you need to do is filter the power supply to the Raduino so the clicks can't get back into the main 12v power rail. Joel? KB6QVI
toggle quoted message
Show quoted text
On Jan 31, 2017, at 4:50 AM, MAc B < sp9mrn@...> wrote: What to do with it? First i thought, that it is software problem with PLL, but it looks OK.
Somebody resolved problem?
MAc sp9mrn
|
The clicks are actually caused by the the time the PLL takes to resettle to a new frequency. It might make sense to disable the output before making the frequency change, wait for a few milliseconds and then enable it again.
- f
On Tue, Jan 31, 2017 at 8:53 PM, Joel Caulkins <caulktel@...> wrote: I assume you are talking about the Raduino clicking as you tune. I'm not having that problem, but others are. One solution is to bypass both the input and output of the 7805 regulator with some 100nf caps. Apparently not all of the Arduino Nano clones are from the same manufacturer and some have better bypassing onboard than others, so all you need to do is filter the power supply to the Raduino so the clicks can't get back into the main 12v power rail. Joel? KB6QVI On Jan 31, 2017, at 4:50 AM, MAc B < sp9mrn@...> wrote: What to do with it? First i thought, that it is software problem with PLL, but it looks OK.
Somebody resolved problem?
MAc sp9mrn
|
Hi Farhan
I went through this issue with the clicks, with the QRP Labs VFO kit . The latest s1.02c firmware version does not have clicks. What Si5351A library are you using? I want to take a look at it. Maybe I can spot some problem.?
73 Hans G0UPL
|
It's etherkit 1xx i suppose but with fixed PLL. : "si5351.set_freq((bfo_freq + f) * 100ULL, SI5351_PLL_FIXED, SI5351_CLK2);"
Should be OK. I also tried Etherkit 2.0.1 with new class "si5351.set_freq_manual()" but with the same effect.
May be the cause is that si5351 is working with arduino without lvl conversion.
I dont know
MAc sp9mrn
|
Hans,
If the clicks while tuning issue is software related, why are some of us not having them and others are and we are all running the same sketch? Joel? KB6QVI
toggle quoted message
Show quoted text
On Jan 31, 2017, at 12:14 PM, Hans Summers < hans.summers@...> wrote: Hi Farhan
I went through this issue with the clicks, with the QRP Labs VFO kit . The latest s1.02c firmware version does not have clicks. What Si5351A library are you using? I want to take a look at it. Maybe I can spot some problem.?
73 Hans G0UPL
|
I used a 22 uF cap paralleled with a .1 (104) cap, bypassing the output of the regulator. ?My Raduino is right above the main board, in a plastic case. ?I also removed all of the excess wiring, and used coax to connect the output to the DDS connector. ?I have very slight clicking only audible when headphones are used. ?I think in the Raduino instance it is power related. ?2 A linear 12V supply feeds my radio.
73\Larry KB3CUF
|
It's a part of the play ;-)
Will try do the trick with supply.
Asshar, I like it ;-)
MAc sp9mrn
|
Farhan, Joel, all, Sorry for the long post - but if you have an interest in this topic, please do read. IF the issue is in the Si5351A firmware configuration (not a hardware matter of more smoothing capacitors etc.) then this is worth reading. First Farhan: you wrote: "The clicks are actually caused by the the time the PLL takes to resettle to a new frequency. It might make sense to disable the output before making the frequency change, wait for a few milliseconds and then enable it again." - this CANNOT be the case, the reason is that in your code you are using a constant PLL value of 900MHz: si5351.set_freq((bfo_freq + f) * 100ULL, SI5351_PLL_FIXED, SI5351_CLK2); SI5351_PLL_FIXED is set to 900MHz in the Etherkit library header file (I am looking at his version 1.1.1 as directed). So Farhan, since the PLL in the Si5351A is set permanently to 900MHz, there is no such thing as the PLL taking time to resettle to a new frequency. The PLL doesn't change - all you are changing is the fractional multisynth divider configuration.? Joel you wrote "If the clicks while tuning issue is software related, why are some of us not having them and others are and we are all running the same sketch?" and that is a good point. But, there is the possibility that the "clicks" being bothersome or not, are somewhat subjective. Some people might have lower background noise than others. So in some cases with high background noise, that could be hiding the clicks. It may just be a hardware problem, I agree. But we shouldn't discount the possibility that it could be a software problem also. So look at both the hardware and the software.? About hardware: At the moment the frequency is updated, remember that the display is also being updated. There is therefore a burst of activity on the signal lines from the processor to the LCD module. It is quite possible that this digital activity is being picked up by the sensitive receiver and is what causes the click. The solution to this could be more supply decoupling and perhaps, some shielding around the Raduino. I'd start with looking at supply filtering. More capacitors in parallel across the supply! Maybe some old toroidal inductor out of an old power supply, in series with the supply to the Raduino!? About software: This was my original question - and the reason for this is that it is very well possible to create an audible click in software also. The QRP Labs VFO kit had this issue, the click was generated by the way I was configuring the Si5351A. It was actually a bug. I fixed it in the current firmware version s1.02c. There is a register in the Si5351A which is used to "reset" the PLL in the Si5351A. When the PLL needs to be reset, and when it does not, is of course not documented (SiLabs documentation is rather poor). But what is sure, is that you do not need to inflict a PLL reset on the situation for small tuning changes, and if you do, you will generate a discontinuity in the output which will show up as a CLICK in the receiver audio. Therefore I wanted to check that the Raduino code does NOT do a PLL reset every time the frequency is changed. Now I see that it fixes the PLL, so there is no PLL reset, and this cannot be the issue.?
By the way, switching off an Si5351A output for a small interval while the PLL settles generates an even worse click :-O ? Not that it is relevant in this case, because here you are fixing the PLL anyway. So now I read the Etherkit Si5351A library again and am reminded how much I disliked it the first time I looked at it ;-) ?It is derived originally from the Linux Si5351A driver. In my opinion it is over-complex and it is inefficient. The use of 64-bit arithmetic seriously bloats up the code size, even worse than using floating point. I did not reply on earlier threads where people were suggesting bigger processors etc., because the 2K RAM and 32K Program space in the ATmega328 is not enough. I did not agree though. You can accomplish a huge amount in 32K program and 2K RAM. Look for example at my Ultimate3S TX kit:??- here I use the same ATmega328. This TX has a rich array of features. It is standalone (no PC connection). It encodes on-chip a lot of digital modes WSPR, JT9, JT65, ISCAT, PI4, Opera. As well as more traditional modes CW, QRSS modes, Hellshreiber. The next firmware version includes JT4 and RTTY as well. GPS calibration, info display, PTT delay, it controls the raised cosine key generation when using the 5W PA ?- all that has no problem with the 2K RAM. I do have to code very efficiently to make it fit in 32K program space. 64-bit arithmetic wouldn't work! So I'm not a fan of that library - and it is over-complex which leads to blind use of it without an understanding of what is actually going on. ? Anyway back on-topic... Using a fixed 900MHz PLL frequency means that you are using fractional division to obtain the desired output frequency. The Si5351A Datasheet recommends even INTEGER divisors in order to obtain best jitter performance. If you fix the PLL you are not using an integer divider, you are using a fractional divider. It will have more jitter. Or in other words, more phase noise. Whether or not this produces a noticeable degradation of BITX40 performance I don't know. This is the reason why in my VFO code I use even integer division. I fix the Multisynth divider at a suitable even integer, and vary the PLL. It is the opposite way around to what is being done in the Raduino. In the Raduino you are fixing the PLL and varying the division (fractionally). In my VFO I fix the division (to even integer) and vary the PLL.?
The Etherkit library is also doing some algorithm to choose the fraction numerator and denominator. This is repeated for each new frequency which is set. It could come up with radically different numerator and denominator, when the frequency is changed. I think that there is a possibility that changing this parameters creates a significant discontinuity in the Si5351A output, which is perhaps enough to cause the click.? My suggestion, is to try it the other way around as I do. Vary the Si5351A PLL and fix the Multisynth division ratio. Use an even integer as this will result in best performance (lowest jitter), both intuitively and according to the datasheet. You might think that the PLL takes time to settle and that this will cause a problem. In reality I think that this is not the case. For the relatively small frequency changes that we are talking about, the PLL will recognise the difference between the current Voltage Controlled Oscillator (VCO) output and the desired new frequency as an error, which it will correct as part of its usual control loop. I think intuitively, that the VCO probably "slides" the frequency to the new value. Much like tuning an analogue VFO, though in a very fast sudden step. But I think it is a fast slide to the new frequency, NOT a discontinuity - since you are leaving the divisor alone. To my mind, this reasoning is logical and it is the best way to ensure no sudden changes which could cause a loud "click".? People have reported that there is now no click when using the QRP Labs VFO to drive the QRP Labs Receiver module. Of course there is always some barely noticeable effect because fundamentally you are applying a sudden frequency shift, and that does produce a set of audio harmonics, as any sudden change does - by fourier transform (like the leading edge of a squarewave). You can't beat the physics. But there is no loud audible click due to an actual discontinuity.? All this is about the software. As others have mentioned - if it is a hardware issue caused by the digital activity radiating, probably by the supply lines, and being picked up my the reciever - then more filtering etc is called for. I just mention all this software stuff in case it is useful, and someone who is modifying Raduino firmware might want to try it out.? 73 Hans G0UPL http://qrp-labs.com
|
whoa, hans, what an incredible find and a neat hack. i tip my new pluto 937 with programmable tempurature control to you! ok, who's first to crack this hack? - f
On 01-Feb-2017 1:53 pm, "Hans Summers" < hans.summers@...> wrote: Farhan, Joel, all, Sorry for the long post - but if you have an interest in this topic, please do read. IF the issue is in the Si5351A firmware configuration (not a hardware matter of more smoothing capacitors etc.) then this is worth reading. First Farhan: you wrote: "The clicks are actually caused by the the time the PLL takes to resettle to a new frequency. It might make sense to disable the output before making the frequency change, wait for a few milliseconds and then enable it again." - this CANNOT be the case, the reason is that in your code you are using a constant PLL value of 900MHz: si5351.set_freq((bfo_freq + f) * 100ULL, SI5351_PLL_FIXED, SI5351_CLK2); SI5351_PLL_FIXED is set to 900MHz in the Etherkit library header file (I am looking at his version 1.1.1 as directed). So Farhan, since the PLL in the Si5351A is set permanently to 900MHz, there is no such thing as the PLL taking time to resettle to a new frequency. The PLL doesn't change - all you are changing is the fractional multisynth divider configuration.? Joel you wrote "If the clicks while tuning issue is software related, why are some of us not having them and others are and we are all running the same sketch?" and that is a good point. But, there is the possibility that the "clicks" being bothersome or not, are somewhat subjective. Some people might have lower background noise than others. So in some cases with high background noise, that could be hiding the clicks. It may just be a hardware problem, I agree. But we shouldn't discount the possibility that it could be a software problem also. So look at both the hardware and the software.? About hardware: At the moment the frequency is updated, remember that the display is also being updated. There is therefore a burst of activity on the signal lines from the processor to the LCD module. It is quite possible that this digital activity is being picked up by the sensitive receiver and is what causes the click. The solution to this could be more supply decoupling and perhaps, some shielding around the Raduino. I'd start with looking at supply filtering. More capacitors in parallel across the supply! Maybe some old toroidal inductor out of an old power supply, in series with the supply to the Raduino!? About software: This was my original question - and the reason for this is that it is very well possible to create an audible click in software also. The QRP Labs VFO kit had this issue, the click was generated by the way I was configuring the Si5351A. It was actually a bug. I fixed it in the current firmware version s1.02c. There is a register in the Si5351A which is used to "reset" the PLL in the Si5351A. When the PLL needs to be reset, and when it does not, is of course not documented (SiLabs documentation is rather poor). But what is sure, is that you do not need to inflict a PLL reset on the situation for small tuning changes, and if you do, you will generate a discontinuity in the output which will show up as a CLICK in the receiver audio. Therefore I wanted to check that the Raduino code does NOT do a PLL reset every time the frequency is changed. Now I see that it fixes the PLL, so there is no PLL reset, and this cannot be the issue.?
By the way, switching off an Si5351A output for a small interval while the PLL settles generates an even worse click :-O ? Not that it is relevant in this case, because here you are fixing the PLL anyway. So now I read the Etherkit Si5351A library again and am reminded how much I disliked it the first time I looked at it ;-) ?It is derived originally from the Linux Si5351A driver. In my opinion it is over-complex and it is inefficient. The use of 64-bit arithmetic seriously bloats up the code size, even worse than using floating point. I did not reply on earlier threads where people were suggesting bigger processors etc., because the 2K RAM and 32K Program space in the ATmega328 is not enough. I did not agree though. You can accomplish a huge amount in 32K program and 2K RAM. Look for example at my Ultimate3S TX kit:??- here I use the same ATmega328. This TX has a rich array of features. It is standalone (no PC connection). It encodes on-chip a lot of digital modes WSPR, JT9, JT65, ISCAT, PI4, Opera. As well as more traditional modes CW, QRSS modes, Hellshreiber. The next firmware version includes JT4 and RTTY as well. GPS calibration, info display, PTT delay, it controls the raised cosine key generation when using the 5W PA ?- all that has no problem with the 2K RAM. I do have to code very efficiently to make it fit in 32K program space. 64-bit arithmetic wouldn't work! So I'm not a fan of that library - and it is over-complex which leads to blind use of it without an understanding of what is actually going on. ? Anyway back on-topic... Using a fixed 900MHz PLL frequency means that you are using fractional division to obtain the desired output frequency. The Si5351A Datasheet recommends even INTEGER divisors in order to obtain best jitter performance. If you fix the PLL you are not using an integer divider, you are using a fractional divider. It will have more jitter. Or in other words, more phase noise. Whether or not this produces a noticeable degradation of BITX40 performance I don't know. This is the reason why in my VFO code I use even integer division. I fix the Multisynth divider at a suitable even integer, and vary the PLL. It is the opposite way around to what is being done in the Raduino. In the Raduino you are fixing the PLL and varying the division (fractionally). In my VFO I fix the division (to even integer) and vary the PLL.?
The Etherkit library is also doing some algorithm to choose the fraction numerator and denominator. This is repeated for each new frequency which is set. It could come up with radically different numerator and denominator, when the frequency is changed. I think that there is a possibility that changing this parameters creates a significant discontinuity in the Si5351A output, which is perhaps enough to cause the click.? My suggestion, is to try it the other way around as I do. Vary the Si5351A PLL and fix the Multisynth division ratio. Use an even integer as this will result in best performance (lowest jitter), both intuitively and according to the datasheet. You might think that the PLL takes time to settle and that this will cause a problem. In reality I think that this is not the case. For the relatively small frequency changes that we are talking about, the PLL will recognise the difference between the current Voltage Controlled Oscillator (VCO) output and the desired new frequency as an error, which it will correct as part of its usual control loop. I think intuitively, that the VCO probably "slides" the frequency to the new value. Much like tuning an analogue VFO, though in a very fast sudden step. But I think it is a fast slide to the new frequency, NOT a discontinuity - since you are leaving the divisor alone. To my mind, this reasoning is logical and it is the best way to ensure no sudden changes which could cause a loud "click".? People have reported that there is now no click when using the QRP Labs VFO to drive the QRP Labs Receiver module. Of course there is always some barely noticeable effect because fundamentally you are applying a sudden frequency shift, and that does produce a set of audio harmonics, as any sudden change does - by fourier transform (like the leading edge of a squarewave). You can't beat the physics. But there is no loud audible click due to an actual discontinuity.? All this is about the software. As others have mentioned - if it is a hardware issue caused by the digital activity radiating, probably by the supply lines, and being picked up my the reciever - then more filtering etc is called for. I just mention all this software stuff in case it is useful, and someone who is modifying Raduino firmware might want to try it out.?
|
Hans, I'm impressed. Thank You
MAc
sp9mrn
|
Hans,
That made my brain hurt:-) Joel? KB6QVI
toggle quoted message
Show quoted text
On Feb 1, 2017, at 12:22 AM, Hans Summers < hans.summers@...> wrote: Farhan, Joel, all, Sorry for the long post - but if you have an interest in this topic, please do read. IF the issue is in the Si5351A firmware configuration (not a hardware matter of more smoothing capacitors etc.) then this is worth reading. First Farhan: you wrote: "The clicks are actually caused by the the time the PLL takes to resettle to a new frequency. It might make sense to disable the output before making the frequency change, wait for a few milliseconds and then enable it again." - this CANNOT be the case, the reason is that in your code you are using a constant PLL value of 900MHz: si5351.set_freq((bfo_freq + f) * 100ULL, SI5351_PLL_FIXED, SI5351_CLK2); SI5351_PLL_FIXED is set to 900MHz in the Etherkit library header file (I am looking at his version 1.1.1 as directed). So Farhan, since the PLL in the Si5351A is set permanently to 900MHz, there is no such thing as the PLL taking time to resettle to a new frequency. The PLL doesn't change - all you are changing is the fractional multisynth divider configuration.? Joel you wrote "If the clicks while tuning issue is software related, why are some of us not having them and others are and we are all running the same sketch?" and that is a good point. But, there is the possibility that the "clicks" being bothersome or not, are somewhat subjective. Some people might have lower background noise than others. So in some cases with high background noise, that could be hiding the clicks. It may just be a hardware problem, I agree. But we shouldn't discount the possibility that it could be a software problem also. So look at both the hardware and the software.? About hardware: At the moment the frequency is updated, remember that the display is also being updated. There is therefore a burst of activity on the signal lines from the processor to the LCD module. It is quite possible that this digital activity is being picked up by the sensitive receiver and is what causes the click. The solution to this could be more supply decoupling and perhaps, some shielding around the Raduino. I'd start with looking at supply filtering. More capacitors in parallel across the supply! Maybe some old toroidal inductor out of an old power supply, in series with the supply to the Raduino!? About software: This was my original question - and the reason for this is that it is very well possible to create an audible click in software also. The QRP Labs VFO kit had this issue, the click was generated by the way I was configuring the Si5351A. It was actually a bug. I fixed it in the current firmware version s1.02c. There is a register in the Si5351A which is used to "reset" the PLL in the Si5351A. When the PLL needs to be reset, and when it does not, is of course not documented (SiLabs documentation is rather poor). But what is sure, is that you do not need to inflict a PLL reset on the situation for small tuning changes, and if you do, you will generate a discontinuity in the output which will show up as a CLICK in the receiver audio. Therefore I wanted to check that the Raduino code does NOT do a PLL reset every time the frequency is changed. Now I see that it fixes the PLL, so there is no PLL reset, and this cannot be the issue.?
By the way, switching off an Si5351A output for a small interval while the PLL settles generates an even worse click :-O ? Not that it is relevant in this case, because here you are fixing the PLL anyway. So now I read the Etherkit Si5351A library again and am reminded how much I disliked it the first time I looked at it ;-) ?It is derived originally from the Linux Si5351A driver. In my opinion it is over-complex and it is inefficient. The use of 64-bit arithmetic seriously bloats up the code size, even worse than using floating point. I did not reply on earlier threads where people were suggesting bigger processors etc., because the 2K RAM and 32K Program space in the ATmega328 is not enough. I did not agree though. You can accomplish a huge amount in 32K program and 2K RAM. Look for example at my Ultimate3S TX kit:??- here I use the same ATmega328. This TX has a rich array of features. It is standalone (no PC connection). It encodes on-chip a lot of digital modes WSPR, JT9, JT65, ISCAT, PI4, Opera. As well as more traditional modes CW, QRSS modes, Hellshreiber. The next firmware version includes JT4 and RTTY as well. GPS calibration, info display, PTT delay, it controls the raised cosine key generation when using the 5W PA ?- all that has no problem with the 2K RAM. I do have to code very efficiently to make it fit in 32K program space. 64-bit arithmetic wouldn't work! So I'm not a fan of that library - and it is over-complex which leads to blind use of it without an understanding of what is actually going on. ? Anyway back on-topic... Using a fixed 900MHz PLL frequency means that you are using fractional division to obtain the desired output frequency. The Si5351A Datasheet recommends even INTEGER divisors in order to obtain best jitter performance. If you fix the PLL you are not using an integer divider, you are using a fractional divider. It will have more jitter. Or in other words, more phase noise. Whether or not this produces a noticeable degradation of BITX40 performance I don't know. This is the reason why in my VFO code I use even integer division. I fix the Multisynth divider at a suitable even integer, and vary the PLL. It is the opposite way around to what is being done in the Raduino. In the Raduino you are fixing the PLL and varying the division (fractionally). In my VFO I fix the division (to even integer) and vary the PLL.?
The Etherkit library is also doing some algorithm to choose the fraction numerator and denominator. This is repeated for each new frequency which is set. It could come up with radically different numerator and denominator, when the frequency is changed. I think that there is a possibility that changing this parameters creates a significant discontinuity in the Si5351A output, which is perhaps enough to cause the click.? My suggestion, is to try it the other way around as I do. Vary the Si5351A PLL and fix the Multisynth division ratio. Use an even integer as this will result in best performance (lowest jitter), both intuitively and according to the datasheet. You might think that the PLL takes time to settle and that this will cause a problem. In reality I think that this is not the case. For the relatively small frequency changes that we are talking about, the PLL will recognise the difference between the current Voltage Controlled Oscillator (VCO) output and the desired new frequency as an error, which it will correct as part of its usual control loop. I think intuitively, that the VCO probably "slides" the frequency to the new value. Much like tuning an analogue VFO, though in a very fast sudden step. But I think it is a fast slide to the new frequency, NOT a discontinuity - since you are leaving the divisor alone. To my mind, this reasoning is logical and it is the best way to ensure no sudden changes which could cause a loud "click".? People have reported that there is now no click when using the QRP Labs VFO to drive the QRP Labs Receiver module. Of course there is always some barely noticeable effect because fundamentally you are applying a sudden frequency shift, and that does produce a set of audio harmonics, as any sudden change does - by fourier transform (like the leading edge of a squarewave). You can't beat the physics. But there is no loud audible click due to an actual discontinuity.? All this is about the software. As others have mentioned - if it is a hardware issue caused by the digital activity radiating, probably by the supply lines, and being picked up my the reciever - then more filtering etc is called for. I just mention all this software stuff in case it is useful, and someone who is modifying Raduino firmware might want to try it out.? 73 Hans G0UPL
|
There was a long discussion of the Si570 and possibly moving to the Si5351 on the minima mailing list a few years ago. ?Much of it still pertains, including discussion of holding the divide ratio constant, moving just the PLL where possible. ?I had written working C code for the Si570 that was about as tight and accurate as I cared to make it, that code is in four lines of code toward the bottom of ?? That code is 32 bit fixed point, with lots of shifts to scale the values to maintain maximum precision. ?Includes some type casts to uint64_t, but only to capture the 64 bit result of a 32x32 multiply. ?That result is immediately shifted an appropriate number of bits and stored as 32 bits. ?Along the line of python code at the top to precompute (and store in flash) a calibration value and some busy work to find values for n1_new and hsdiv_new when the PLL goes out of range, the 4 lines of C code toward the bottom are a complete and very accurate working example for the Si570. The Si570 was problematic in that they were factory programmed to a specific output frequency, but you could not easily determine what that frequency was by reading registers on the chip. ?And you needed that value to calibrate the reference oscillator inside the Si570. ?The Si5351 doesn't have that issue, as it uses an external 50ppm crystal reference, so we're forced to calibrate each unit individually. ?Registers are much different on the Si5351, but the same tricks of fixed point arithmetic will apply. Transmitting some of the digital modes is possible from a small uC by steering the Si5351 around and modulating the keying envelope. ?Receiving is much tougher, but possible in some cases. ?I wrote a program in 2006 for psk31 reception on a TI MSP430, that's in the files section on the yahoo AT-Sprint group under KE7ER/psk31uc.c ? It simulates well, though didn't have the patience to figure out Steve's assembly language for the AT-Sprint well enough to shoehorn in my C code. ?I'll try to move file that over to this group under files/KE7ER sometime today in case anybody's curious. ?A likely better PSK31 receiver is this from OK1IAK: ??? ? Both of these psk31 decoders should fit in uC's with something like 256 bytes of RAM and 2kbytes of flash. ?I haven't tried either one on the air. Jerry, KE7ER
On Wed, Feb 1, 2017 at 12:22 am, Hans Summers wrote: You can accomplish a huge amount in 32K program and 2K RAM. Look for example at my Ultimate3S TX kit:??- here I use the same ATmega328. This TX has a rich array of features. It is standalone (no PC connection). It encodes on-chip a lot of digital modes WSPR, JT9, JT65, ISCAT, PI4, Opera. As well as more traditional modes CW, QRSS modes, Hellshreiber. The next firmware version includes JT4 and RTTY as well. GPS calibration, info display, PTT delay, it controls the raised cosine key generation when using the 5W PA ?- all that has no problem with the 2K RAM. I do have to code very efficiently to make it fit in 32K program space. 64-bit arithmetic wouldn't work! ?
|
Very weird. ?I uploaded a couple files a few days ago, was easy enough. ?Now I can't. ?Can still create a new folder just fine. ?Did some sort of "UploadFile" button disappear from the groups.io web interface? Jerry
On Wed, Feb 1, 2017 at 09:26 am, Jerry Gaffke wrote:
I'll try to move file that over to this group under files/KE7ER sometime today in case anybody's curious. ?
|
The tuning clicks on my Raduino were eliminated with some DC filtering to the Raduino supply rail. ?From memory, a 10 0hm resistor in series with the Raduino supply and a 470uF cap to ground on the Raduino side. ?A 100n cap also in parallel with the 470uF. ? The only thing bugging me now is the TX/RX pops from the speaker and carrier burst on key up. Cheers, Glenn VK3YY.
|
Hi Glenn,
My bitx40 originally had loud clicks whilst tuning is changing, decoupling the supply to the Raduino board helped a lot, it does not totally eliminate the clicking, but with the antenna connected you can't hear any clicking, when the antenna is disconnected, turning the volume to maximum position a faint clicking can still be detected. The modification of adding the decoupling should be done as a matter of course.
Cheers Alf vk2yac
Glenn S wrote:
toggle quoted message
Show quoted text
The tuning clicks on my Raduino were eliminated with some DC filtering to the Raduino supply rail. From memory, a 10 0hm resistor in series with the Raduino supply and a 470uF cap to ground on the Raduino side. A 100n cap also in parallel with the 470uF.
The only thing bugging me now is the TX/RX pops from the speaker and carrier burst on key up.
Cheers,
Glenn VK3YY.
|
I used AD8950 module based oscillator and?this too has the click sound while tuning.? Probably the same reason.
regards Sajeesh
From: Ashhar Farhan <farhanbox@...>
To: [email protected]
Sent: Wednesday, 1 February 2017 1:59 PM
Subject: Re: [BITX20] Tuning clicks
whoa, hans, what an incredible find and a neat hack. i tip my new pluto 937 with programmable tempurature control to you! ok, who's first to crack this hack? - f
|
Hi Jerry
> There was a long discussion of the Si570 and possibly moving to the? > Si5351 on the minima mailing list a few years ago.? Much of it still? > pertains, including discussion of holding the divide ratio constant,? > moving just the PLL where possible.
That's good to know that others reached the same conclusions that I did. In the QRP Labs kits I am using only 32-bit arithmetic for all the Si5351A computations. There is one place where 64-bit airithmetic (or less optimally, floating point) would be required in order to maintain precision. But I have an iterative routine which manages this step with 32-bit arithmetic. It really keeps the code tight, and makes lots of spare space in the Flash memory for all the other interesting things required!
73 Hans G0UPL
|
Hi Alf, Had a listen to the radio last night with the antenna connected and if there were clicks they were down at the level of the internal receiver noise.? Cheers, Glenn VK3YY.
|
I have no clicks from my Raduino at all, even with the vol all the way up and the antenna disconnected I cannot hear any clicks while tuning. Strange that some do.
toggle quoted message
Show quoted text
On Feb 2, 2017, at 3:47 PM, Glenn S < glenn.vk3yy@...> wrote: Hi Alf, Had a listen to the radio last night with the antenna connected and if there were clicks they were down at the level of the internal receiver noise.? Cheers, Glenn VK3YY.
|
Joel Caulkins/N6ALT