mlp6 / adpl Goto Github PK

check package.json

hard mount point for all boards and cable routing

The analog reading of the level sensor (output is variable current that I run through a resistor for voltage reading) is not being read by the Arduino, though it can be read by a multimeter.

The assembly is a magnet attached to a moving object (the bucket that tips every time it is filled with 300 mL of treated liquid) and a fixed sensor in the middle of the tipping bucket's pathway. The wires attached to that sensor send a current each time the magnet passes. The apparatus I showed you only counts the number of times the magnet has passed the sensor. Instead of that apparatus, we will attach the sensor's wires to our circuit board, and the Electron will do the counting. I want the internal clock to tell me at what times the bucket has tipped.

Latest code in the master branch is ready for testing. As before, I wrote all of this blindly, but did verify compilation of the code.

Once the code is in a fully-functional form, we can explore the final phase of making it truly modular, but if we don't get to that milestone, you will still have a fully-functional version of code before your trip in a few weeks.

You can create Issues for any bugs that you encounter and aren't sure how to fix; otherwise please edit away and let me know when the code is "ready".

@aforbis-stokes would it be valuable to trace the water level when we also track the temps?

Right now, in loop(), to following steps are performed serially:

1. Sample data on each probe
2. Average data on each probe
3. Convert each average to temperature (C)

The same exact operation is being performed for each probe, so will write a new probeTempRead() function that will do all of the "action" and then just loop for each probe in loop().

Plotting 8000 points can cause some performance issues on the front end, and it seems we dont really need to plot at the resolution that we do. Is there some merit to simply downsampling the data we are plotting by, say, a factor of 2?
@aforbis-stokes

when temperature > 65 C for > 30 min

need to map pins to function in a way that is robust for slight variations in different deployments. would like to have the function names be universal, and the actual pins be what can change, especially since a blown pin in the field could trigger and on-the-fly redirect to a new pin

new particle platform will require new connectors, and a previous issue was electrical connectivity to the Uno. need to add strain relief to all connections and hard anchor points to enclosure.

@aforbis-stokes estimated current data usage for 2.5 min publish events for 5 temperature probes to be ~13.2 MB/month, which will not be cheap. Some ideas to reduce this data usage are to reduce the precision of data being published, maybe report stats over larger time intervals.

include power supplies and other misc. electronics hardware

Generate a CSV of data for a given location (include all channels)

Get valve status on demand. Should we also publish this along with the other data periodically? @aforbis-stokes

In addition to the electron publishing data, add the ability to poll the device for temperatures on demand. I'm guessing this will require Spark.variable() declarations for all variables that will be polled.

Hopefully these can be added in the data stream of things also being published, but maybe not all of the thermistors... or maybe you can choose which ones.

I'm not sure how much data the request will add on top of the data sent back.

need to create a web portal for data logging and alert notifications

https://github.com/suyashkumar/provision

changes should be made to Pump.h and Pump.cpp

Ignore negative values when plotting (in front end). @aforbis-stokes

As it was, compiled code took ~110% of available memory. Aaron reduced to ~99%, but we need more breathing room for variable space.

@aforbis-stokes What is your timeline / when do you leave for your trip to have a board done? (I will be gone Fri - Wed.)

We have a few options for board design to consider:

• Use perf board to mount all hardware, with wire / solder connections.
• Layout a printed circuit board with DipTrace that we could either etch in-house or send out to be etched.

Perf board might be totally fine for this since you don't have any surface-mount components. PCBs would be great if you had to replicate a lot, but you only need 1 for the near future, correct?

provides max 0.15 A output; needs 2 A @ 5V

What other "at-a-glance" type of data would be good to show in the dashboard? Maybe the avg temps over the last hour for each probe?

@aforbis-stokes
@mlp6

the particle uses a 12-bit analog input pin, not a 10-bit pin like the Arduino

Running the pump and ignitor on separate timers that will not conflict has been challenging.

Enough current flowing through some of the digital pins to switch my relay even when the setting is LOW.

handle-device.js: data.data.split -> parse by key name

@aforbis-stokes is reporting that the temperatures at being published too frequently

current single-shot (HIGH) lasts <=1 s, so need to lockout the counter for that 1 second interval; should make a private variable to declare this duration in case the hardware changes down the road.

Currently 4 different voltages are needed in the circuit:

1. 5 V - Arduino
2. 24 V (0.5 W) - water level transducer
3. 12 V (2 W) - valve
4. 1.5 V (0.42-0.48 W) (280-320 mA) - ignitor
5. 12 V (48 W) (6 A) - Pump

Ideally we can use one DC transformer that can be regulated down to each DC voltage w/ adequate power supplied to each one.

With the current settings we're essentially pulling down and plotting the entire database at once. Is this what we want to be doing? Are we most interested in plotting the last N days in the dashboard? @aforbis-stokes

record temperature on all of the thermistors and save to the cloud

It appears that earlier versions of C++ will not allow what the header error message says... so things that compiled fine on my system aren't compiling on Aaron's system, which I'm guessing is using an older version of the C++ compiler. I'll move these initializations to the constructor.

It would likely be useful to download the currently drawn plot as a vector SVG.

currently the 'mA' values are meaningless to the end user and confuse the logic

same type as before... previous issue was memory to handle all of these in parallel