Replies: 26 comments 9 replies
|
Thanks Brian, I'll have a look at how the KiwiSDR does this, it's not ever been something I've thought of (particularly as I find I often want to tune a few Hz off a round frequency to get the tone 'right' when listening to SSB), so I'll need to get an idea of the best way to implement such a thing so you can still fine tune as needed. However if it's been done before I expect it can be done here too. That said I do need to finish two or three 'big ticket' items from the envelope list first before casting around for a new envelope with free space on its back to start a fresh list :-) |
|
So I had a quick look at how to implement this (still haven't seen the KiwiSDR operation!) and I have it roughed out and working in my development system now. However there is a problem of sorts since I like to be able to tune in 10Hz increments at times. So what say you to having just the largest step (5kHz or 9kHz) snap to nearest 1000Hz, and leave the other steps alone? The step sizes are somewhat arbitrary, presently they're in steps of 5or9kHz, 100Hz, or 10Hz. That can be changed, and one could make it also snap to the nearest 100Hz for the next step down for example, but I'm reluctant to do that without a pressing case (and it's easy for people to alter the code themselves if they'd really want it like that). |
|
Yes, it would be perfect to have the outermost + / - buttons tune and snap to the nearest 1 kHz—that’s exactly how KiwiSDR does it. For reference, on KiwiSDR, the next set of + / - buttons tunes and snaps to the nearest .5 kHz, and the lowest (innermost) + / - buttons tune and snap to the nearest 10 Hz. The outer buttons will snap you to the nearest 1 kHz, regardless of where you are currently tuned. For example, if you’re tuned to 7272.14 kHz, and you press the outermost + tuning button, it would tune the receiver to 7273.0 kHz. Have a look at any KiwiSDR http://kiwisdr.com/public/ to see examples. I’m not sure if the tuning buttons on KiwiSDR are configurable or not. Thanks! |
|
Excellent, I posted an addition an hours or so ago that should implement this (that is to say, 'snapping' with the outermost buttons). Let me know if it works ok / is as you expect? Cheers. |
|
I find the buttons too close together when using it on my phone. Can you tell me what I should change to make them appear more separate? There is room for it....... Cheers! |
|
Sure, You'll need to edit index.html and locate the lines beginning with '<img id="id-step-0.... etc', the first should be around line 190? From the second of these, replace the section that says 'style="padding-bottom:0px"' with one that reads 'style="margin-left:6px"', do that for each through to, and including, the last - which will probably need it added as I don't think the padding detail is included on that one. Save the file and you should be good to go, adjust the 6px to whatever suits you. Finally, FYI, while there's nothing to the right of those icons presently I do have something in mind that could occupy a section of it at least, so the index file (and free space) could change. |
|
This is awesome. I think there may need to be some slight tweaking to this feature to get it right. I'm finding that I'm having to click the outermost +/- buttons a couple of times in order for it to snap correctly. The intent is that if you see a signal on the waterfall, you can click "close enough" to it, and then "lock on" to the nearest 1 kHz using the +/- snap buttons. Continuing the example from above: If you’re tuned to 7272.14 kHz, and you press the outermost + tuning button, it would tune the receiver to 7273.0 kHz, but if you clicked the outermost - tuning button, it would tune the receiver to 7272.0 kHz. Here's a screen capture of my use of this feature, and how I am finding that when I try to snap up or down, often it will go too far (perhaps the math needs to be revisited), so I need to snap back and forth until it lands on the right frequency: https://www.youtube.com/watch?v=B6MBu8ubTus |
|
Thanks for the video clip. To explain how I've got this at the moment; there are three 'click' tuning steps, +/-10Hz, +/-100Hz and either +/-5kHz or +/-9kHz. For your 'snap to' I have taken the absolute value of the +/-5/9kHz step plus the current offset frequency, divided that by 1000, rounded the result, multiplied it by 1000 and applied that as a new offset frequency (from the center frequency you set for that profile). This seemed to me to be a simple way of achieving the outcome you wanted, but perhaps it's flawed. I'll need to think about it, but if you've got any further insight that could help - particularly bearing in mind this isn't something that was even vaguely on my radar, and math isn't my strong point! Just to give a little more input, I could do similarly for the waterfall click perhaps, and/or changing the fundamental frequency steps is trivial. For the latter at least I'd probably just tell you where that is in the code and you could change them to suit yourself since we'd probably get into a situation where what's right for one person isn't for another etc (mainly me, 'cos I'm happy with those step sizes at present :-) |
|
Hmmm, interesting: Maybe these changes by @jwt27 would assist? I don't think anything fundamental has changed in the code since then that would prevent them being used. Fairly easy to trial anyway. |
|
I completely understand that this is an additional feature that wasn't on the radar. Thank you for even considering it, not to mention actually adding the feature into the latest build! This may just be my personal preference, but, borrowing from how KiwiSDR's outer tuning buttons work, here's an example of what I would expect to happen when tuning and snapping to the nearest 1 kHz: While tuned to 14.165474 MHz, pressing the outermost tune down button (-), should take me down to the next 1 kHz, which in this case would be 14.165000 MHz. Likewise, if I were to press the outermost tune up button (+), it would tune the receiver to 14.166000 MHz. However, with the current build, when pressing the outermost tune down button (-), the receiver tunes to 14.16000 MHz. I believe my misunderstanding/expectation of the "snap to nearest 1 kHz" function is perhaps complicated by the fact that the outermost buttons are also tuning up/down in 5/9 kHz increments, and they go beyond the expected 1 kHz snap distance. Another possible way to accomplish the snap to the nearest 1 kHz function is to mimic what WebSDR does with a ".0" or "=kHz" button in the middle of the tuning buttons to snap to the nearest 1 kHz. I hate to even mention the possibility of adding another button to the receiver panel, as I know there is limited real estate. I also don't assert that my proposal (borrowing from KiwiSDR) is the right one. I know that there are probably multiple ways this functionality could be added without taking away what's already there and not accommodating others' preferences. I am actually keen on your suggestion of being able to customize the tuning step sizes based on user preference, given that the outer buttons would still snap to the nearest 1 kHz in either direction. Let me know where that is in the code and I will play with it and see if I can get that working the way I need. Again, thanks so much for your effort here! I really do sincerely appreciate all your help and contributions! |
|
Ok, I do think there's possibly a divergence of expectation here :-) First perhaps try adjusting the frequency steps in the code to what you'd like, then see if it'll work how you anticipate. The requisite section in openwebrx.js starts at line 71 and finishes at 113. The step frequency sizes should be clear, you could just change those that say '5000' to say '1000', save the file, then reload the browser to trial. In this instance the largest steps would normally be 1000Hz, then if you toggle the change button they'd still be 9000Hz. If you're not interested in BC stations you could change the 9000 to some other number, making that toggle more useful to you. It's also entirely possible to add the rounding for the lower steps, but first let's see if the above gets it working how you want. |
|
Nice! I changed the value from 5000 to 1000 and -5000 to -1000 and that
totally worked the way I was anticipating. Thank you! I will continue to
make these edits in my own personal instance. Not sure what BC stations are.
…On Tue, Jul 12, 2022 at 3:25 PM eroyee ***@***.***> wrote:
Ok, I do think there's possibly a divergence of expectation here :-)
First perhaps try adjusting the frequency steps in the code to what you'd
like, then see if it'll work how you anticipate. The requisite section in
openwebrx.js starts at line 71 and finishes at 113. The step frequency
sizes should be clear, you could just change those that say '5000' to say
'1000', save the file, then reload the browser to trial. In this instance
the largest steps would normally be 1000Hz, then if you toggle the change
button they'd still be 9000Hz. If you're not interested in BC stations you
could change the 9000 to some other number, making that toggle more useful
to you.
It's also entirely possible to add the rounding for the lower steps, but
first let's see if the above gets it working how you want.
—
Reply to this email directly, view it on GitHub
<#2 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAD5LT6CTIVA2FG6IGKBZT3VTXPDDANCNFSM5ZUGLCBQ>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
Excellent, that's good to know, thanks for following up. BC = Broadcast, sorry, I should probably have used m/w or something similar, trying to be economical on the keys ;-) |
|
I changed the 5000/-5000 step increments to 1000/-1000 and the 9000/-9000 step increments to 500/-500 so that I can toggle between 1 kHz and .5 kHz steps. But, I think there's something strange happening. Here's the scenario: I have a signal on my Airspy at 7.1690 MHz. I click on the waterfall to tune approximately and I land on 7.16941 MHz (a little bit above the target signal). I want to snap down to the nearest 1 kHz (which would be 7.1690 MHz). So, I click the outermost tune down button, and instead of taking me to 7.16900 MHz, it tunes the receiver to 7.16800 MHz (too low). Clicking the outermost tune up button takes me back to the target signal. Here's a video of it: https://www.youtube.com/watch?v=LDvoxREgRkA Any idea why it is skipping from 7.16941 MHz to 7.1680 MHz instead of going to the nearest lower 1 kHz (7.1690 MHz)? Thank you! |
|
Short answer is no! (I have no idea :). If I create the same formula in a spreadsheet, for example '=ROUND((B4)/1000)*1000' where B4 is the cell you enter the frequency in, it appears to work as you wish/expect. I can enter 7169410 and it gives me 7169000. So, without looking further at this point (I've been/still am working on something else) either js is doing something weird or, more likely, I've messed something up. To that end I'll need to have a closer look at it operating in real time before I can determine what's going on, which I'll do when I get a spare moment... |
|
No worries, Ivan. Let me know if you need me to test or take any action on my side. Thank you for your time and consideration. I really appreciate it. |
|
Hello, I am changing the javascript code to better suit my need. |
|
Yes, that's the way it works. If you've made changes to a js file all you should need to do is reload the browser - I generally operate in 'private mode' and flush the cache etc to ensure there's no interaction from any earlier code. |
|
Hello eroyee, I have made an change which I would like you to consider for your version of OpenwebRX. How can I send you this change? The change does:
|
|
That sounds like something that @bhall7 would like :-) Just so I'm clear - does this add another button to the receiver GUI, or are you double-clicking an existing button to change the step jump? FYI I've been talking with another person regarding adding options to the settings menu. One of those options would likely be the step frequencies, so that people could change them to suit their needs, which is probably useful as individuals appear to have their own preferences on this. Doing it this way avoids more buttons too, which is probably a good thing (although I'm not as bothered about that as some :) I added the 5/9KHz switch because someone mentioned they wanted that for broadcast DXing, but I've had no feedback either way on it... There's a whole lot of things one could do (for example automate the switch to 9KHz steps when that band is tuned) but for me this was a simple way of enabling it, however it could easily be re-purposed - was this what you had in mind, or have done? Regarding code, have you forked & implemented your changes their already, or are you working on it internally? |
|
Hi, I don't know the fine details about forking etc with GIT. I am of the CVS generation haha I just made a third toggle to have the toggle be: 1kHz, 5kHz, 9kHz, 1kHz etc etc I need to fork your repository you say? I will have to read up on how GIT works, I only used GIT in a team of developers...all using the same repository Tux |
|
There's no need to read up, it's not really my thing either - I only used Github 'cos it was where the two main branches of the code already were. So more than happy to just add your code in directly, you could either post it here, or send via email. However I'm still not sure if this is adding another button (or more), or you're adding further toggle steps to existing? BTW, talking of generations, I had to build my first computer - at a time when I was at courses learning about valves! :-) |
|
Oh my gosh, I wire wrapped my first 6809 computer on euro-card size boards.....time flies :) I will try to create a pull request haha |
|
(grabs popcorn) |
|
Cool, thanks @TuxTiger , I'll trial it out today or tomorrow and then come back to you and/or merge as needed. BTW I don't suppose you know anything about C++? I've been battling with a direct connect for the miri library the past few days (which is why I hadn't done much more with this recently) and things are moving rather more slowly than they should... @bhall7 I hope it's the nice sticky sweet popcorn ;) |
|
I don't have any C++ experience I'm afraid. I stopped using C few years after the Internet became common....and script languages like Perl became my main language. |
|
Thanks (re c++), probably a good move given the mess I've managed to create in a short time! Anyway, on to your mods. I like what you've done with the frequency steps click+second-click, and the additional step toggle, and can't see any particular issue anyone could have with this. One suggestion though - how about updating the mouseover hover-text to reflect the new options? Regarding the pan change; I suspect this is more of personal preference thing, although I've never used OpenWebRX on a telephone browser and don't really use these buttons myself, so can't comment with any authority. I had thought about reducing the shift range when I first implemented this for @bhall7 but presumed the least number of clicks to pan the maximum range was more desirable. However I don't have a strong view and, on balance, I can imagine it being possibly a little easier on a small screen (?) so am happy to include this and see what Brian thinks - but same comment re the hover-text. Finally, I try to comment my code where I think people might want to experiment or alter things - I see this as being helpful and perhaps assisting some to learn and maybe contribute one day, also it's good to acknowledge the author for various reasons. I wonder if you see any value in a few comments? Perhaps where you're multiplying the pan shift x 0.5 for example - a comment here to say what it does and what the effect might be in changing that? Overall really appreciate the input and would be happy to merge all (except perhaps for the button spacing :) but just wonder what you think about the above comments before I do that? |
|
Okay, no problem. Your functions "canLeft" did you mean panLeft() ? |
|
Can = canvas ;-) Strictly speaking shifting the canvas left or right is the opposite of panning (shifting the focus/view) left or right, hence I used that for the variable name 'cos I thought it more easily understood from a logic perspective? |
|
So I've committed your changes now, thanks. I then returned the freq icon spacing back to nil but pointed out your spacing convention in the additional comments, hope that's ok? I think that in the future a separate html file for mobile browsers that adjusts such things is probably a good idea. Amazing what two people who probably compiled the very first few versions of NCSA Mosaic back in the day can do when pushed :-) @bhall7 will be keen to see what you think. BTW the variable naming convention can be quite fraught when dealing with existing code. Usually I like quite short variables for obvious reasons, but given the rest of the code, and the intended audience (who I hope will experiment and learn from it), I've tended to keep them longer and write more comments. Hopefully someone will thank us for that one day... |
|
Gents, YES! You guys are so awesome! This snap tuning function is working as expected. Such a huge improvement in usability! Thank you! 🙌 73 BHall |
|
@eroyee great! I will be afk for a few days. I was having my holidays and from today I will do a cycling trip for a few days ;) |
|
Cool, I'll assume you're nowhere near me then; you'd be very wet on a standard cycle, enjoy! |
|
Great to hear! I am also using this black version with my mobile and tablet every day on my holiday location. Thanks for your message! |
Uh oh!
There was an error while loading. Please reload this page.
I would love to see an option to snap to the nearest 1kHz. Perhaps this could be integrated into the step tuning controls like KiwiSDR does.
All reactions