1) Electronics:
- Xbee for WiFi
- Arduino to control the LED's and button toggle
- Battery
2) Software:
developed with LiveCode
A hand held WiFi unit acting as a standalone Stopwatch paired with a "work station" (PC, Mac, Pi, etc.) and running the Stopwatch software
To make the experience fit your profile, pick a username and tell us what interests you.
We found and based on your interests.
1) Electronics:
- Xbee for WiFi
- Arduino to control the LED's and button toggle
- Battery
2) Software:
developed with LiveCode
JPEG Image - 2.13 MB - 03/03/2016 at 22:55 |
|
|
JPEG Image - 2.08 MB - 03/03/2016 at 22:55 |
|
|
JPEG Image - 1.76 MB - 03/03/2016 at 22:55 |
|
|
fzz - 12.61 kB - 03/03/2016 at 22:32 |
|
|
Portable Network Graphics (PNG) - 389.52 kB - 03/03/2016 at 22:32 |
|
|
Present days:
25-Feb. 16 to be precise - helped by Arduino forum I had the Trinket 5v toggle the LED's as needed (see the forum for details). Since the Xbee works with 3.3v I am replacing the Trinket 5v with Pro Trinket 3.3v
26-Feb. 16 - a forum thread has been opened on the LiveCode forum. The initial post on the forum regarding the COM port communication is here, contains some code snippets and some good advices.
27-Feb. 16 - Replaced the Trinket 5v with Arduino Pro Mini 3.3v ATmega 328P-AU since I had the unit in hand. I would do prefer to use the Pro Trinket 3.3v due to the USB connector and the mounting holes (need to buy one). Modified the Fritzig schema accordingly and test the LED toggle on the breadboard.
03-Mar. 16 - Drilling, wiring, soldering, powering and testing ... apparently it works, had data stream on COM4 port and the LED light would change accordingly. Moving on with the software side of it, LiveCode here I am!
History 2015: working in a manufacturing environment, directly involved in production management a clear need for a solution (system) to monitor the production time as often as possible has been identified. Every product goes to different production phases, each phase consuming time accordingly. The sum of time from each production phase for a given product will give us the "total time / product x". When you have a plethora of SKU's (more than 5k) and the time / each has been determined years ago (a person with a stopwatch in hand) you realise pretty quick that the production line reality in terms of productivity does not correspond any more with the actual times registered in the company system, so the problem arises quick when the pty. (productivity) target is 100% and you struggle to get 90% - meaning you loose money money money ... (ask my boss about it).
The phenomenon that modifies the "time": well the products evolved in terms of construction, improvement of the manufacturing line, personal fluctuates, etc. All this will affect the "actual time / product" while the "system time / product" will remain the same since the person who should time periodically the production time flee ...
The born of the idea: one management meeting day (not the best one) the tedious and crazy task (among all the other) assigned to me has been the "timing" ... As a daily reader of Hackaday and Kikstarter surfer I knew there is an answer for my problem, and there was under different forms (ESP8266 WiFi buttons, Amazon DASH button, Kikstarter campaigns with Bluetooth buttons, even more buttons if you Google'it) but I needed a tailored solution. And my journey started by reading the internet related button projects for about 2 months, I was reading like crazy everything that came in hand, from hardware to software drawing in my mind the building plan. Every time I had a question I had to search deeply on the internet to find the answer (there is always a solution or as one of my friend told me once "every problem has 3 solutions").
Proof of concept: before you go and pitch to your boss about a solution usually works better if you have a "proof of concept" and this was mine (actually I had 2): the 1'st (for myself only) - I needed to prove that a button can trigger a specific action so one night (one of those nights when your mind does not stop popping questions) I opened my old cell phone, cables, chargers, etc. box and pulled out the old Nokia Bluetooth headset (perfect it has a button and is Bluetooth). Put it to charge and meanwhile open the MIT app Inventor and start adding blocks that would do the following: if the phone rings and the call is activated (by my headset button) then start a timer to count seconds. When the call is ended stop the counter .... Eureka! Eureka! it worked. Well all good for the following days but you can not go for the pitch with your Nokia headset and explain that is the solution (you loose your job right!). The 2'nd (for the pitch) proof of concept - remember I read everything for a period of 2 months? well that paid off at this time. Purchasing the Bluefruit EZ-Key from ADAFRUIT came to rescue and offered my the first proof of concept for the pitch. A weekend spend on soldering and software development with MIT app Inventor and I was ready for the pitch (I had a plastic case from a toy with Start/Pause/Stop buttons linked to my phone).
The pitch: all good on the introductory part regarding the concept and the hardware till the question arises: what is the Bluetooth range? and the answer is 10 m. max. :( ... (what I have a fully working proof of concept solution ready in your hand and you want WiFi? r u kidding, I was screaming in my head) not good enough for my boss, now he wants 100 m. and no Bluetooth (he heard about WiFi); so no deal unless I make it WiFi to cover 100 m. range and reducing the costs by eliminating the Android tablets that would run the stopwatch app. controlled by the button. After another month...
Read more »
Create an account to leave a comment. Already have an account? Log In.
Become a member to follow this project and never miss any updates