Future Design Discussion - v2.0

Added by Jeremy Wright about 11 years ago

As we look towards the kit version of Shepard that will hopefully be widely used for educational purposes, I'm looking for everyone's thoughts on software.

Right now, the Shepard data collection software is written in Processing. This language/platform was chosen because of it's coupling (and parental connection) with the Arduino language and IDE. It was also chosen because it's designed to be easier for non-engineers and non-programmers to use. I've come to like Processing more as I've used it, but I personally still prefer a language like Python.

Since this version will be used in education, I was thinking about setting the main application up to be a TCP server that other client GUI frontends can connect to. This would allow any student machines on the same network to view and download the data from the test stand in (almost) real time. There are several different design options that come to mind when thinking about this:

  1. Don't mess with this, nobody will ever use it.
  2. Keep the current Processing app with the built-in GUI and try to add a TCP server to that. Then write a separate "Shepard Viewer" app that connects to the TCP server.
  3. Break the current Processing app down to a TCP server (non-GUI backend) and a TCP client (GUI frontend). Then all systems (including the main one for the test) would be running the same client. Each client would have the option of recording data separately.
  4. Break the current Processing app down to a non-GUI server only, and have that serve clients with a dynamic HTML 5 app to display the data. This adds some other challenges such as security, data storage and speed, but it would allow any device (tablets, laptops, cell phones) to take part in the test without installing anything.
  5. Keep the Processing app with the built in GUI for speed and stability, and have it serve HTML 5 to any other clients.
  6. Use a language like Python to accomplish any of the above options.

I haven't checked yet to see if Processing will serve web pages without a ton of coding. I know that Python will though.

So, any thoughts on any of this?


Replies (16)

RE: Future Design Discussion - v2.0 - Added by Aaron Harper almost 11 years ago

I think we have addressed these. Use the new BeagleBone Black, program it however you'd like, and have the bone do the heavy lifting, presenting the data on an active web page on it's own server.

RE: Future Design Discussion - v2.0 - Added by Jeremy Wright over 10 years ago

CCSSC asked about direct measurement of the exhaust stream, and that led me to another short round of research. That led me to this: http://www.melexis.com/Infrared-Thermometer-Sensors/Infrared-Thermometer-Sensors/Thermal-infrared-thermopile-sensor-for-high-temperature-measurements-779.aspx

In short, it can read up to 1030 C, but it uses the SMBus interface instead of I2C.

RE: Future Design Discussion - v2.0 - Added by Jeremy Wright over 10 years ago

Oh, and there's this too for later versions of test stands. It actually has an array of sensors to give you a low resolution thermal image.

http://www.melexis.com/Infrared-Thermometer-Sensors/Infrared-Thermometer-Sensors/FIRray16X4-Far-InfraRed-Array-776.aspx

RE: Future Design Discussion - v2.0 - Added by Jeremy Wright over 10 years ago

We've talked about the possibility of using the Adafruit Arduino Trinket in the finalized Shepard 2.0 kits.

http://www.adafruit.com/products/1501#Learn

I found the deal killer tonight while reading the documentation. The serial port can only be used for programming, not for communication. There's a workaround for Windows, but not Linux or Mac.

RE: Future Design Discussion - v2.0 - Added by Christopher Sigman over 10 years ago

Jeremy, where does it say that it can't be used for comm? All I see is that it can't be used for debug, which to me isn't the same thing, but I could see meaning that in general it can't be used for comm, so I wanted to check.

RE: Future Design Discussion - v2.0 - Added by Jeremy Wright over 10 years ago

http://www.adafruit.com/blog/2013/10/15/how-to-fake-usb-serial-with-a-trinket-the-adafruit-learning-system/

The main page for the Trinket doesn't say "communication", but it won't work with the Arduino serial monitor which I take to mean that it won't work with our current Shepard UIs.

http://learn.adafruit.com/introducing-trinket/

Trinket does not have a Serial port connection for debugging so the serial port monitor will not be able to send/receive data

RE: Future Design Discussion - v2.0 - Added by Christopher Sigman over 10 years ago

I didn't see that page; that confirms it in my mind. Another alternative might be the one Aaron brought up a week or two ago: http://www.dfrobot.com/wiki/index.php/Beetle_SKU:DFR0282 I haven't looked at it in terrible detail yet, but it's supposed to be fully compatible with the Leonardo, so I would assume that it doesn't have the same comm limitation. It might be a little more of an assembly challenge in using one of those, but I think it's very doable.

RE: Future Design Discussion - v2.0 - Added by Jeremy Wright over 10 years ago

Yep, and at $7 each in packs of 10 they're pretty cheap. Looking at the pinouts, we should be able to do one analog input and one I2C bus at the same time without any trouble. I'd be a little gun-shy on getting too serious about it yet though since it's a pre-order item and we don't know how stable their supply chain will be. If they're chronically sold out they won't do us much good for kits. I do like the concept though.

RE: Future Design Discussion - v2.0 - Added by Jeremy Wright over 10 years ago

This will mainly be of interest to Chris.

I'm thinking that we should discuss switching the timestamp back to an unsigned int and then try the following:

  1. Max the timer out at 65535.
  2. Use the "Enable Recording" button to tell the Arduino to 0 and hold the timer.
  3. When the thrust value goes above 0 start the timer on the Arduino.

This would remove 2 bytes of data from each send and sync the timestamp zero to the first data point.

Thoughts?

RE: Future Design Discussion - v2.0 - Added by Jeremy Wright over 10 years ago

This will mainly be of interest to Chris.

I'm thinking that we should discuss switching the timestamp back to an unsigned int and then try the following:

  1. Max the timer out at 65535.
  2. Use the "Enable Recording" button to tell the Arduino to 0 and hold the timer.
  3. When the thrust value goes above 0 start the timer on the Arduino.

This would remove 2 bytes of data from each send and sync the timestamp zero to the first data point.

Thoughts?

RE: Future Design Discussion - v2.0 - Added by Christopher Sigman over 10 years ago

What would be the pro's of switching back? The decrease in packet size would mean an increase in data rate. Can anyone think of anything else?
What are the con's of switching back? My biggest concern is if the collection doesn't stop for some reason before the time is all eaten up, I think our average user would get freaked out by how the data looks in those cases, especially the graph with a line trailing from the right most data point back to the left most. There might be other concerns, but I can't think of much at the moment for this one either.

RE: Future Design Discussion - v2.0 - Added by Jeremy Wright over 10 years ago

Pro 1: Faster sample rates.
Pro 2: Would force zero time to be sync'd with the first data point.

If we freeze the timer when it's zero'd and only start it when the value goes above zero, the user would have 65.5 seconds to finish their sample run before the timer runs out. This could paint us into a corner with a delayed stop feature like CCSSC has requested. If the user wanted to measure the temperature casing cool-down cycle for 2 minutes after the test firing started, they'd be out of luck.

RE: Future Design Discussion - v2.0 - Added by Christopher Sigman over 10 years ago

I think the zeroing can be part of the req regardless of whether we use 2 or 4 bit timestamps. In terms of sample rate, IIRC with the current 4bit timestamp we still have sustained for several minutes a sample rate >1K, but even if it is a bit shy I think the rate is still more than adequate, and prevents the issue you laid out with the cooldown cycle. The other option is to have the software adjust the timestamps so the wrapping isn't an issue, but this goes into the fact that now the data isn't quite the data.

RE: Future Design Discussion - v2.0 - Added by Jeremy Wright over 10 years ago

Agreed - So it sounds like we're leaning towards sticking with the long value and zero-syncing it. Is that correct? Anybody else have any thoughts?

RE: Future Design Discussion - v2.0 - Added by Christopher Sigman over 10 years ago

Yep, I think that's the best option, unless anyone else has any other insight.

RE: Future Design Discussion - v2.0 - Added by Jeremy Wright over 10 years ago

While fixing a bug in the Processing app this morning I noticed that we're already essentially doing this, it's just on the client side. That keeps the load on the Arduino low. However, I typically try to keep the creation/control of a timestamp as close to the original data source as possible, so I'm going to still add this as a feature request for Shepard v2.0.

(1-16/16)