HobbyPCB.com

Built by Hobbyist for Hobbyist!
It is currently Wed Aug 21, 2019 11:47 am

All times are UTC - 5 hours




Post new topic Reply to topic  [ 6 posts ] 
Author Message
 Post subject: needs updates
PostPosted: Sun Nov 25, 2018 10:00 am 
Offline

Joined: Sun Nov 25, 2018 9:45 am
Posts: 2
I have noticed that aftera week of use that all though the radiois a great performer it needs some tweeks to the soft ware , 2 problems both the same cause I think, first the radio is near impossible to time in a station whilst in 100khz steps, the encoder "bounces" and jumps three hundred kilohertz or so. The encoder can be "debounced" in software, the other problem i have is the touch screen needs the same debounce treatment, trying to change from af to rf adjust takes 6 or 7 tries sometimes.
The radio performs really good and checked into E-cars net with a solid 5/9 on a 1/4 wave vertical 40 meters..

I'm NOT bashing the radio, it just needs some tweeks. Maybe have a filter bandwidth number instead of the breast useless rsl.
Colin K0LIN


Top
 Profile  
 
 Post subject: Re: needs updates
PostPosted: Tue Dec 04, 2018 10:21 pm 
Offline

Joined: Mon Nov 05, 2018 6:54 pm
Posts: 11
Hi Colin

Thanks for the feedback and congratulations on your 5/9 check-in.

The encoders already have a state machine control to ensure accurate tracking and I don't understand why it would track differently on 100kHz steps versus any other decade setting. I'm curious how you could fine tune using 100kHz steps since each step is enormous and could have dozens of stations between. I would only use the 100kHz steps to rapidly move up/down the band then change to 10kHz or 1kHz steps for fine-tuning. I can't say I have observed the skipping identified but then I normally have it set to 10kHz or 1kHz steps, so I'll have to test it. The steps are pretty close and it does require fine adjustment. I'll get back to with what I find.

Similarly, I have not had any problem pressing the screen buttons and wonder how you are doing so? You might try using a stylus for better control. I usually buy a 10 pack for under $10 from Amazon. When touching the button with a finger, I usually use the fingernail since it is more precise than the blunt end of the finger. Again, I have made a note to do some more testing and see if I can reproduce the problem.

I did not understand your suggestion "Maybe have a filter bandwidth number instead of the breast useless rsl". Perhaps you could clarify, please.


Top
 Profile  
 
 Post subject: Re: needs updates
PostPosted: Sat Dec 08, 2018 5:40 pm 
Offline

Joined: Sun Nov 04, 2018 2:03 pm
Posts: 3
sorry about the typos, i typed it on my phone and the auto correct did the rest!
i was referring to the 100Hz tuning steps, when tuning say 14,200,100 it will increment pretty good till you get to say 14,200,700 then it will jump to 14,201,000 or sometimes 14,202,000, it constantly "over shoots" or bounces on the encoder. hope that makes more sense.

The RSL number bounces about and that "on screen" button could maybe better used to show the filter bandwidth setting as there is already a signal strength reading on the left side of the screen.

Is the firmware open source? i could find no trace of it online.
colin K0LIN


Top
 Profile  
 
 Post subject: Re: needs updates
PostPosted: Mon Dec 10, 2018 12:40 pm 
Offline

Joined: Mon Nov 05, 2018 6:54 pm
Posts: 11
Thanks for the clarification - I had a hard time with the autocorrect - it shows even the phone makers have problems interpreting finger pushes! Thank you for your suggestions. I checked out your reports and have a rather long reply...

With regard to the button pushes, I can reproduce this problem. It seems that when pressing with a blunt finger it does not detect the push. A smaller contact with the screen works every time. I'll need to take a look touch algorithm and see if we can relax the touch parameters. As I said previously, using a fine point such as a fingernail or stylus is very precise.

The tuning seems to operate as expected but is not perfect. We have spent considerable effort getting it to work the way it does. To explain the design, the encoders generate a grey code which feeds into a software state machine with 8 states: 4 track clockwise motion and the other 4 track anticlockwise motion. Transitions between the sets of 4 represent a change of direction and would trap debounce producing no change in the frequency value. This would work perfectly except for the fact there is a single processor polling the encoder state. As a result, if the encoder is rotated quickly the input can skip grey code values and even alias. The correct solution to this is to track grey code counts in hardware and there was a late modification to connect the encoder input to a counter. However, the software has not been changed yet.

The way I test the encoder functionality is as follows. Rotate the encoder "slowly and carefully" in one direction and confirm the counts increment. Change directions and confirm the counts increment in the opposite direction without skipping. The testing I have done on my development unit shows perfect tracking! The encoder operation is rather fine and it is easy to rotate beyond a single step. If the unit does not track at these low rates then it might indicate a defective encoder.

We could make the frequency change to be less sensitive, but this exacerbates the rapid motion aliasing problem. Once we implement the hardware change in counters connected to the software, the high rate tracking should be fixed. However, there is a significant amount of work to be done to change the software together with lots of other features which has not been prioritized or scheduled.

On the final point, the filter bandwidth is represented by the yellow line below the spectrum. I suppose we could show a numerical value, but the RSL numeric values is a legacy and I don't know who uses it.

Speaking of legacy, the firmware is a fork from the STM32 SDR project on Github which had a large group of contributors. I tried to keep the code common, but there were just too many RS-HFIQ specific requirements that made the common code hard to maintain. Essentially, development of older STM32 SDR has now stopped and all the new development for IQ32 is being done by me.


Top
 Profile  
 
 Post subject: Re: needs updates
PostPosted: Tue Dec 11, 2018 3:39 pm 
Offline

Joined: Mon Nov 05, 2018 6:54 pm
Posts: 11
I have investigated the finger pressing problem on the touchscreen. Unfortunately, the screen only generates an interrupt when the touch is constrained to a limited part of the screen. There is nothing we can do in software to detect large finger presses. I did try varying the touch closeness threshold but it makes very little difference since the touch is qualified in hardware. Unfortunately, the only solution is to make the touch contacts with narrow parts of the finger or use a stylus.


Top
 Profile  
 
 Post subject: Re: needs updates
PostPosted: Thu Dec 13, 2018 10:43 pm 
Offline

Joined: Sun Nov 04, 2018 2:03 pm
Posts: 3
Thanks for your very detailed reply, very informative. i will use the spare stylus that i have for one of my nintendo's. i love the radio, and to get over the encoder steps i just set finer steps when i'm close to a station. i would have preferred the steps to be cycled through by pressing the encoder the way most encoder tuned radios do, that way it is easier one handed. but im learning to use it the way t is for now.
colin K0LIN


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 6 posts ] 

All times are UTC - 5 hours


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group