reilleya / rmts-software Goto Github PK

The user should be able to set the percentage of max thrust that is used to determine when a firing begins and ends.

Load cells and pressure transducers should be treated separately in the code so you can pair different sensors without having to add all combinations as profiles.

Whenever the application opens a file selection window, it should default to showing the last directory that they picked a file from.

If a user hits "Connect" and does not have transducer set, things sort of get locked up in the workflow. Also, at this point the user cannot edit the firing parameters on the right side. Both scenarios involve exiting the sw.

This could be addressed by several options:

• a text comment that one needs to set these things before connecting
• pop up that says you need to set transducer and firing data if you try to hit connect and haven't
• a "disconnect" button that allows you to go back and set stuff
• splitting the firing page into two panels, one for "Firing setup" and then a "Firing"

Just some thoughts.

There should be a workflow that allows the user to gather calibration data for a sensor. The flow should look like:

1. Select a COM port to connect to. The software should ensure that the device is sending setup packets.
2. Select which sensor (load cell or pressure transducer) to calibrate.
3. Open an interface that shows a graph with the current regression. Have a box where the user can enter the current "real" value. Grab the average of the last ~5 sensor packets and plot the resulting point on the graph. The user should be able to view the data points on the graph alongside the regression as well as view and delete them in a table. They should be able to click "cancel" to exit and discard the results, or confirm to save them.

There should be an about page with the standard safety disclaimer and thanks for Peter and Shreeyam. This might also be a good spot for a way to connect to an RMTS board and display version info.

Revise rounding so this shows up at 0.0 instead.

I can probably filter out faulty radio packets that manage to pass the checksum based on the fact that time only increases as sequence ID goes up.

For tests with both pressure and force data the thrust coefficient should be calculated and graphed, with an average displayed.

It might be worth stretching the flame slightly

Add a button to the results screen that allows the export of the raw data as a CSV.

There's no time to capture calibration frames when the board is triggered externally so the software needs to not remove these frames if this is how the motor was started.

Every file generated and consumed by the application should have an attached version number to allow for migrations. Just copy the system from oM.

Just a little convenience thing.

Move log file to appdirs directory, and figure out how to load resources properly so the logo on the start screen is displayed.

Holding the fire button down should send a constant stream of fire packets. Pressing it should send significantly more than it does currently, maybe 50.

The propellant characterization menu should allow you to load data from multiple firings and perform a regression on their data to output the ballistic coefficient and exponent along with a plot of c* for different pressures to judge combustion completeness. The user will likely need to enter additional information to go along with each file, like propellant web thickness.

There should be a logger that handles both file logging and displaying certain levels of output in popups to inform the user. It should make sure the log files don't exceed a certain size and all that good stuff.

Right now the only sign that the device has errors is the data age going up, which is impossible to distinguish from the board not being on. The error display from the fireWidget should be extracted and made usable here as well.

For example, it would be nice if there was a popup when the first results packets arrive so the user knows things are happening.

It could be a good idea to require the user to hold a modifier button down to enable the fire button in addition to the text box used currently.

Apparently useful for importing into other tools

Right now if you run a test with only a pressure transducer you have to switch to "Raw" mode because the flat-line force data coming in will get trimmed to nothing. There should be a "None" option in each transducer dropdown that disables anything related to that transducer later in the UI. If load cell is set to "None' then trimming should be based on pressure data instead.

No transducer will ever have a ratio of 0 and it causes a lot of problems downstream.

The application should have a page where it displays the contents of error packets from the board so the user can resolve the issues. There should be detailed explanations of what the errors are and how they can be fixed.

The ADS1219 only returns values in the 0x0 - 0x7FFFFF range for positive inputs. As we only expect it to have to read positive values, packets with force or pressure outside of this range can be discarded.

If a firing is completed with the wrong transducer selected the user currently has to manually edit the file, which isn't great. There should be a button that allows a user to change the transducer calibrations used for processing a file.

There should be a checkbox somewhere that allows users to turn on grid lines on the graph widget.

Based on the max value the ADC/amp can read and the calibration for a transducer we can calculate what physical reading the system will max out at and display it so the user can avoid disappointment.

The log file doesn't capture exceptions which makes debugging most problems remotely difficult.

There isn't much that can be done to guess which COM port is the correct one on windows, but on Mac OS and Linux the application should pick the first option that doesn't contain the string bluetooth as that is often the first option alphabetically but never correct.

If the RMTS board is already sending results when the firing widget connects, the firing object will send the application to the results page without any indication of the reason. Skipping automatically to the results page makes sense when the user has just pressed stop button but not as much here, so I should figure out the right way to direct the user to the "receive results" workflow instead, maybe by having the firing complain when it gets a result packet before sending a firing packet.

You should be able to display a stream of data from the other transducer on the calibration screen. This would be useful for calibration techniques like I use for my load cells.

There should be a way for the user to locate their openMotor propellant file and add data from the characterization tool to it.

Sensor information should be loaded from a file that the user has a nice way to edit.

It seems that the calibration table isn't cleared after saving a calibration which leads to false points being shown if you attempt a second calibration.

The "Process Raw Data" menu should be wired up so a user can view raw data in the SD card format. This will require tweaks to the start screen because it is currently set up so the sensor profile dropdown is associated with the "Wireless connection" option when it is also required for viewing raw data.

Add a button for exporting a PNG of the graph along with some stats, like the TRA puts out for certified motors.

The user is left in the dark when the stop button is pressed if they are looking at the logs as it can take a few seconds for the first graph to appear. There should be some indication that results are arriving before the transition to the results screen so they know things are working.

The software currently overwrites the propellant and configuration files with defaults if the loaded file fails validation. This is usually the correct behavior as a file that fails validation isn't useful most of the time, but bugs in file validation or normal development could lead to this happening when it shouldn't. Users shouldn't lose their calibrations when this happens, so if the file exists when it goes to write the defaults it should move it to ___.yaml.back or something

First, it seems like the logic for handling time rollovers is only used for reading from MFL files, not when receiving results directly from a board. Verify that this is the case and fix it if so. Also, Harry sent me an extremely long data file (6+ minutes) and it seems like the time data got messed up when it went past about 2 minutes. This might be an error in the rollover logic.

Check the same condition that makes the progress bar appear to see if they should be asked about saving before exiting the view.

This is both friendlier to the board and more correct, because the firing time in the packet maxes out at a value.

Have it show the current board state inferred from what packets are being received. Include a stop button so it is useful for trigger mode.