tonyc / open890 Goto Github PK

Need to draw the SVG's at 2x width (1280px and 424px for the bandscope and audio scope respectively), but there's a bunch of other assumptions the SVGs are being made about their widths, so there's more work than I was expecting.

Basics:

• General architecture
• Building from source (Linux/Windows - separate pages)
• Other stuff I can't think of right now

Filter edges for the audio scope are currently not implemented.

This will allow displaying it in the passband filter spectrum

Span is shared between CENTER and AUTO SCROLL, but when switching to FIXED, the span is actually calculated, not set directly from a command response.

When switching from FIXED to CENTER, the radio does not send a new band scope span response, so the net result is the edge frequencies are incorrect.

Band scope span needs to be tracked independently for fixed mode.

afdsdfdsf

End goal: CI-built images for various RPI models that people can just directly burn to an SD card, and go.

I'd like Nerves to not take over the whole repo, but I've never used Nerves before, so this is a tracking issue/discussion for possibilities and options.

FF seems to get laggy, I think it's related to how I'm drawing the individual pips for the meters.

Need to figure out a different way of generating the pips or changing the classes. It might be more efficient to draw a cyan/red background behind a "window" of fixed pips, and then just dynamically adjust a single <rect>'s width behind the windows.

Hover over frequency and scroll? Specific digits?

It would be nice to have a simulator for the physical radio, which would allow the app to be demoed "offline", or perhaps also facilitate testing.

The simulator could operate at either the TCP or the Genserver level, and it should be able to keep some of its own state, while generating random fake bandscope data etc.

tedfsfsdfsdf

It would be super useful to have an "auto-start" option on a per-connection basis, and open890 would do so upon starting.

Would be cool to have it mobile/tablet friendly

Need to strip down the UI considerably and get the bare minimum fitting into a single screen.

Navigation via keyboard would be really useful.

Ideas

• vim-style shortcuts? hjkl, gl for LSB, gu for USB?
• Direct band switching with numpad?
• Arrow key fine tuning

Format: RM[P1][P3][P3][P3][P3]

ALC (1) should be tracked separately, 2-6 can be grouped together if need be.

P1:

• 1 - ALC
• 2 - SWR
• 3 - CMP
• 4 - ID
• 5 - VD
• 6 - TEMP

P3 is 0000 through 0070

Needs UI/UX.

How is this distributed? Perhaps a docker image, or a single executable.

Probably need to set up CI/CD release process

ALC and SWR meter's first pips have a little cyan tint to them.

It looks like there's an extra pip being rendered at the end of every meter as well

Need to figure out how this will look and work.

Might need to use a in order to draw individual pixels, but also need to make it all line up with the spectrum.

How does this look on the UI?

It's nice but doesn't seem to help much when we've got something like Electron available for running and distributing the app.

• Remove bakeware dep
• Remove from release process
• Update CI to only run MIX_ENV=prod mix release

Is there a way to capture PCM samples in the browser?

Required for full remote TX operation

Should be pretty easy once #19 is completed

There's a general desire to run or build open890 on Windows 10, but without using WSL.

If anyone is interested, you can try it out by downloading the Windows version of Elixir, checking out the code, and seeing if you can get it up and running.

If that works, then it should theoretically be possible to do a binary release using Github Actions automatically.

Not happy with all the whitespace and general layout.

Vertical gridlines should be drawn every span_khz / 10 khz

So if the span is 10 khz, the gridlines are drawn every 1 khz, and follow the frequency as it changes.

This is currently prevented in the UI, but the controllers need to prevent it as well.

The plumbing is all in place.

Mostly need to figure out playing PCM samples in the browser.

It looks like we can use low-speed versions of the DDn commands, so USB support will mean more than just frequency and button state is available.

This may require fair amount of refactoring of the existing code, and probably need to create a USBConnection module, and then also deal with any shared behavior between is and the TCPConnection.

This also affects the LiveView components, as the bandscope and audio scope return far fewer buckets of data.

USB commands for scope data

To the radio:

• DD04 - Bandscope on, COM/USB, AI linked
• DD12 - Filter scope on, COM/USB (Low cycle)

From the radio:

• DD2 - 20 buckets of bandscope data
• DD3 - 19 buckets of filter scope data

Blocked by #50

Instead of setting ENV vars, there should be a basic UI that allows users to manage connections to the radio, start/stop them, etc.

Draw the actual frequency at the bottom of the scope, at every other gridline.

Center & Auto-scroll mode

• Every other gridline, starting frequencies that end at 0 khz (e.g. 7.000, then 7.002, 7.004 for 10 khz span)

Fixed mode

• TBD

It would be cool for the system to maintain a TCP connection to a packet cluster, and overlay spots on the band scope.

Allow the user to define their own buttons (e.g. PF1-9) to input a list of commands to execute.

Potentially also allow the buttons to be named.

Consider a WAIT or PAUSE pseudo-command to allow for the radio to settle in certain cases when needed.

Center mode functionality is mostly unimplemented since I use auto-scroll most of the time. Get basic passband display working on the band scope.