Have you ever just missed the actual problem by a mile?

Just thought I'd share this with the hope that someone else will find this heartening. (Warning: might be a bit long and waffling - its probably better not to read it, but I wanted to write it.)

About 3 years ago, I got my first arduino kit - It was thrilling, I had been playing around with pics and stuff, but the assembly was getting in the way of me creating stuff. As the arduino was based on C, and I had some experience with this, I was like a fish in water.
About ten minutes after making a few leds blink and getting an LCD work, I started wondering what I could do with it that could make my life a better one.
Then I thought - what about all my snakes and other pets? Thermostats are expensive in the petworld, coming in at £30 for a very simple single model, so I set to work.
I added feature after feature, and worked hard to ensure that the circuit was all mains safe.
I worked out ways of keeping time (accurate enough for me) and only switching relays one at a time.
Eventually I ended up with a lovely piece of kit that had the following features:
Arduino controlled relay box, with 10 outputs.
Umlimited temp sensors possible for each relay (instead of taking one sensors reading, they were averaged)
Each relay could be a thermal relay for heaters, or timed for lights
LCD screen for standalone mode and buttons for setting all variables.
Serial communication to allow for computer based data-logging.

All seemed to be perfect - or as near as I needed it to be - UNTIL:

I then set about configuring my pc to log the data I was now collecting in droves, but every now and then, the USB port would lock up - no data would come in for a few minutes, and usually when it did resolve itself, it was on another USB port... eg would switch between /dev/ttyUSB0 and /dev/ttyUSB1 (Im using linux).
I was at this time, using shell scripts to collect the data, and send time updates to the USB port, and I was limited in how precise a control I could get - but it worked (mostly), and I wrote a script to check which port was there and ran the appropriate script. The odd thing is that the arduino would work perfectly, without a reset through this - and commonly showed uptimes of 90+days, even though the USB port dropped 10-20 times a day (although sometimes it didnt drop once)

A friend at this point suggested that the problem might be due to electrical noise from the relays. I tried everything I could to clean it - opto-isolation (I thought it still leaked throught the mains wiring in the house) didnt seem to work, nor did putting all the seperate parts on different power supplies. There was also the strange factor that it seemed to happen regardless of relay states. ie it could happen when they were all off, or all on or anywhere in between. After a few weeks - I gave up, and accepted that as it worked, I would study on, and see if I could build a mkII without this problem.

As I have never written any executables for linux before, I thought that the next logical step was to get into practice, and write a C program to collect the data more reliably, [Note to self, NEVER program the serial port in C again] or so I thought, as the data came in, and would work fine, but in the way of all experiments - soon as you left it alone, it reverted to a mess of errors. I ended up running it once a minute and killing the previous one (if still running). This gave me a readable graph, without any messy gaps, but some of the data was still off every now and then (values transposed etc).

Then I started finding out about a component I had never really understood - The capacitor. What a cylindrical wonder this is, and I thought as I learnt more about power spikes, I thought that finally I had a fix.

Lots of values were tried, more data read, google started to fade from overuse, my wife laughed at me wanting datasheet sarnies for work... and to no avail.

Then one day I read that the arduino, rather than being C based as I assumed, was actually C++ based, so I thought why not have another crack at this problem, and at least try to clean the data a bit more before passing to my datalogger. Well, well, to my surprise, it was a LOT easier, and allowed for much finer control of the ports, so I decided to go right for it.
As I had become accustomed to the serial.print() debug method while playing with the arduino, I started using it in my C++ code as well (or the equivalent) and started to notice a few things about the data I was parsing:
Errors always seemed to occur while data was being transmitted by my time syncher script (I had forgotten about that - apart from knowing the time was right all the time), or errors also occurred when a read was not completed by the previous program before I killed it (as it would readock from time to time).

As I had never logged the errors in this level of detail, I was gobsmacked! I hastily rewrote my data collector program for my arduino with the following changes:

Only use 1 program to communicate with the arduino on each serial port.
Turn off data output on arduino before sending new times (as when time is updated, it confirms it).
Start each collecting session by enabling my arduino output.

I have now finally (just as I type this) had my first complete 24 hours of data without a single error or transposition. My serial port has remained static, and Im feeling a fool for not realising that the problem was pc software related, not arduino software/hardware related.

Lessons learnt from this:

  1. I am an idiot (I might as well say it as I know you lot are too polite)
  2. I wish I had started taking part on here earlier - someone may have helped me.
  3. Plan your communication better, and try to use standardised data packets with start/end and crc bits
  4. Stick at it, the solution will come in the end as long as you never give up and keep trying new things.
  5. Put the time in - its worth it.
  6. Glue is hot,
    solder is too,
    glue melts,
    and now I know fingers do!

I am currently working through a backlog of fun parts I got from ebay to play with including:
RTC clocks, latches, LEDs, etc

I plan to try a day simulator with an array of RGB leds to provide my geckoes with natural colour for dawn/dusk and also to give a moonlight glow for them to hunt at night with.

What fun!

That was an enjoyable read! Nice to hear that you kept at it until you got success.

I am still learning myself so, I go back and forth between stopping with frustration and starting new, fresh attempts. It is nice when things finally work correctly1

Thanks for the feedback!

Well, as I said above, Ive been working on it for years - not full-time, but on and off.
It was functioning correctly as a thermostat, but the logging was flaky.... not important enough to fix now, but irritating.

The bit that has caused me the most amazement was the difference in how I addressed the [virtual] serial port, and the results from each.

I will also now admit, that the best thing to do is re-write the arduino software to send better data packets, but having learnt so much since I built it, I would rather redo it completely (SSDs are in the post from china!! hooray) with all the new tricks I have learnt.

The best bit is, from all my searching while looking for the problem (in the wrong place) I have learnt far more than if I had done it all correctly.
BONUS: I finally learnt the basics of capacitors, and also know exactly why you use diodes and capacitors with motors and relays...

36 hours now and clean data all the way.... woohoo!

Congratulations! And rest assured, you are in very good company!

Making mistakes is useful, it allows us to recognize them when we make them again... XD

they say you learn by your mistakes
maybe that's why i know so much!

well done for persisting though

ghoti:
Lessons learnt from this:

  1. I am an idiot (I might as well say it as I know you lot are too polite)

No, you are not an idiot. Not at all. Some of the best engineers in the world have times like this; times when we pull out all our hair, struggling to find a solution to an issue we -know- is there, but we just can't find the cause. It sounds like you got and tried various advice (good advice, too - possible relay noise, and capacitor decoupling were both plausible symptoms of your issues). But eventually with perseverance, study, and understanding, you've managed to solve your problem (and learned a thing or two along the way).

That doesn't sound like an idiot to me; an idiot would've given up, complained, whined about the issue, then moved on to something else - and never take the time to understand and solve the issues in a manner that would lead to a solution (however long it took).

You are certainly no idiot in my book!

ghoti:
2. I wish I had started taking part on here earlier - someone may have helped me.

This is true - but isn't it just a wee bit more satisfying that you got there on your own? Really, it's knowing when you are at your absolute wits end; that you've tried everything, given it your best, etc - that's when you need to step back, relax a bit, don't look at the project for a while (if it isn't an emergency, and you have other ways to take care of things - whatever they are - if needed), then write out something describing the issue, your problems, your tried solutions, and how they didn't work (and possibly why they didn't work - even if it is just a guess). If you have empirical data, put that in too. You might be surprised at how often just setting down these thoughts can lead to an "aha!" moment for you. But if not, you can then use this documentation to call for help from others, including it in whole or part (as needed) to help them understand the issue, and help you with a solution.

ghoti:
3. Plan your communication better, and try to use standardised data packets with start/end and crc bits

Overall - planning of a project from the outset, top to bottom (with versions or stages), along with goals, timelines, process diagrams, etc - can all help to create the optimum solution...

Then again, if you haven't heard of "Defect Driven Design" (D-cubed) - it's an idea that is so crazy on it's surface, it just might work! :stuck_out_tongue_closed_eyes:

Really, though, for most Arduino projects, IMHO, you don't -have- to go down a completely planned and organized engineering route. Recognizing the complexity of the project though is key, and understanding what are "critical" pieces that should be worked on -first-, and possibly planned and debugged in detail, can help towards a workable solution (generally, if a project needs or requires security, communications, or both - those areas should be planned out and worked on absolutely first, rather than tacked on at the end - both tend to be things very difficult slot in place after the rest of the infrastructure is there).

ghoti:
4. Stick at it, the solution will come in the end as long as you never give up and keep trying new things.
5. Put the time in - its worth it.

Very true on both points; as before though, I would suggest if you get in a real pickle where you're at the end of your rope - step back, take a break, don't look at it for a day or so. Do something else (go for a walk, a drive, a swim - whatever helps you, just not anything to remotely do with the project). Many times when you come back, you'll see things with fresh eyes and come up with a solution. As noted above, write out your problem and things you've tried in detail at this point; this act of "documentation" may help you with a solution (even better, you could try keep a logbook as you build the project, with notes, etc - such documentation can be very helpful in debugging issues). Finally, when "trying new things" - try them in a logical step-by-step manner. Resist (it is very difficult, but important) to try two different solutions to a problem (or two different changes to solve a problem) at the same time; you might find that you introduce more (or different) bugs this way (not something you want - this is a hard learned lesson, believe me)! Change one thing, note the difference and whether it helps or not, then move on from there.

ghoti:
6. Glue is hot,
solder is too,
glue melts,
and now I know fingers do!

So, so true... :smiley:

When I posted this, I never actually imagined any responses - I just needed to get the whole story off my chest, and as I don't have much contact with many other fiddlers of electronicy arduiny things, I thought I would post here in the belief that someone would understand it.

I have had a dream of working with electronics since I was a kid but never found anyone who could teach me.

I have fiddled with BASIC/C programming for years, but lost interest as it could not affect "Real World" stuff.
I learnt to solder while working on an assembly line (Handy cos I can do surface mount) about 14 years ago, and have slowly been learning about circuitry.

5 years ago, I finally started with a PIC, but after a year or so I was introduced to the arduino.

Hopefully this can be a tale of inspiration for some, entertainment for others. For me its just a relief to find what the cause was - not to mention finding it in the most unexpected place.

My main thoughts today (nearly 60 hours of fault free data) are what should I do next:
Re-write software for the (now rather outdated, but perfectly working) circuit or
Redesign the circuit with my new knowledge to improve and add extra features then recode.

Although as I now have more animals, I might work on the redesign so I can build it in a more modular manner, and have several units rather than just the single one.

Overall - planning of a project from the outset, top to bottom (with versions or stages), along with goals, timelines, process diagrams, etc - can all help to create the optimum solution...

Then again, if you haven't heard of "Defect Driven Design" (D-cubed) - it's an idea that is so crazy on it's surface, it just might work! smiley-yell

Planning is something I am working on, but apart from the goals, it all just flows as its needed. This is one area I need to work on a lot more is pre-planning all my variables.

I am now putting everything else on hold to investigate "Defect Driven Design" - It sounds like my kind of design! :smiley:

To quote Galaxy Quest "Never give up, never surrender!"

ghoti:
I am now putting everything else on hold to investigate "Defect Driven Design" - It sounds like my kind of design! :smiley:

Honestly - D^3 is an idea mainly suited to projects to be delivered to a client (it's not really something you can use on yourself). The idea is that your project instantly starts in maintenance mode (because that is where all projects for clients end up). Rather than getting a client proposal, planning the project, having the client change plans, re-planning, then coding (and while coding having the client change ideas - forcing you to recode, etc) - maybe never getting to QA, or limping thru QA, then delivering a "completed" project, only to find you have to do bug fixes, etc - you instead put the project in "maintenance" (debugging) instantly.

This process allows you to have the fastest possible deliverable, and without all the nastiness of planning and having the client change the plans. Instead, they give you the plans somewhat "piecemeal" and you code to that over time, and every step of the way, you are fixing bugs/problems to make the system more robust and stable, growing it along the way.

The steps are "roughly" as follows:

1 - Client requests a design (let's say a web application); you say "done", it's on the server (you don't actually write any code or do anything)
2 - Client returns and says "I load up the URL and all I get is a 404 error" (that's your first defect - put it in the bug system and fix it with a blank index.html page)
3 - Client returns and says "Ok, now it comes up, but it's blank - it's supposed to have this and that, and work like so" (second defect; add those options)
4 - Client returns and says "But I can't see widget X, and button Y doesn't go anywhere, and fields A, B, and C don't save" (third defect - fix again)
5 - etc, ad-nauseum, until the end-of-time

From a certain perspective, it looks and seems like madness; from a different perspective, though - it seems like pure genius - like it would probably work (???)...

As you can see, though, this process might not work so well if you are the developer -and- the client (unless you can really compartmentalize your thoughts and ideas to such a point that you might be fundamentally broken as a human being)...

:smiley:

I was starting to enjoy enjoy reading about the process and identifying with my programming style... then you had to go and put this :

As you can see, though, this process might not work so well if you are the developer -and- the client (unless you can really compartmentalize your thoughts and ideas to such a point that you might be fundamentally broken as a human being)...

I now realise why my wife hates me coding.... I do become broken as I tend to get rather focused at times... My best 5 hours of coding is the "half hour" after saying "Im coming up to bed in a minute love" XD

Still, for all that, I would much rather be doing something creative than soduku!

ghoti:
I now realise why my wife hates me coding.... I do become broken as I tend to get rather focused at times... My best 5 hours of coding is the "half hour" after saying "Im coming up to bed in a minute love" XD

That sounds like me and my wife...

Focus is a completely different thing from compartmentalizing; focus can be good - compartmentalizing to the point where you are essentially two minds in one body, where neither is aware of the other (which is what would be required for D-cubed to work properly within a single person's brain) - well, that would likely be classified as a psychological issue, I would think...

I will also now admit, that the best thing to do is re-write the arduino software to send better data packets, but having learnt so much since I built it, I would rather redo it completely

This is often a good thing to do. Write some code to validate each thing you need to do, then combine those bits to construct a workable application. Then, knowing what works and what doesn't throw it all away and write a new program from scratch. 9 out of 10 times, the new code will be shorter, faster, and have fewer as-yet-undetected bugs.

The 10th time, reuse the original code.

All
I enjoyed reading this post. It really feels like "it could have been me." :smiley:

As to the "defect driven design". I have been in IT for way to long and for more than a decade as an architect. I understand the organizational beauty of this approach but as an Architect I hate it.
And then I read this:

As you can see, though, this process might not work so well if you are the developer -and- the client (unless you can really compartmentalize your thoughts and ideas to such a point that you might be fundamentally broken as a human being)...

And I realize this is actually how I develop with with Arduino:
1 - I want a web application; I get an ethernetshield
2 - I say "I load up the URL and all I get is a 404 error" (that's my first defect - put it in the bug system and fix it with a blank index.html page)
3 - I says "Ok, now it comes up, but it's blank - it's supposed to have text" (second defect; add text)
4 -I says "I want a button to get the Arduino values" (third defect - fix again)
5 -I says But I want all Arduino values (add values)

I did 3 and 4 yesterday evening. XD I know I have all these defects already in mind and you may call this a plan, but if in the progress something changes there is no plan to adopt and no defect to be canceled, there is no time pressure, no allocated resources..... And this reduces overhead. And indeed it makes me look "broken as a human being". Especially with my girlfriend. :~
Best regards
Jantje

Jantje, you put into words what I meant when I said I felt like I was already broken!

I tend to work with a general goal in mind... but add each bit at a time, need to plan a bit more, but it works for now.

One thing I forgot to mention is the benefits of having something like subversion holding all the versions of code.
Too many times I have "broken" working code, and cant figure out where I borked it all up - subversion lets me do rollbacks and merge previous versions. Ok, I use more storage for my code... but at a couple of kb a version... its well worth it.

Im glad to hear that my story isnt unique, and I have enjoyed the replies very much so - thank ou all for taking the time to read it!

On a side note... 2 weeks of clean data now and still going strong... :smiley:

Jantje:
And I realize this is actually how I develop with with Arduino:
1 - I want a web application; I get an ethernetshield
2 - I say "I load up the URL and all I get is a 404 error" (that's my first defect - put it in the bug system and fix it with a blank index.html page)
3 - I says "Ok, now it comes up, but it's blank - it's supposed to have text" (second defect; add text)
4 -I says "I want a button to get the Arduino values" (third defect - fix again)
5 -I says But I want all Arduino values (add values)

I did 3 and 4 yesterday evening. XD I know I have all these defects already in mind and you may call this a plan

I'm going to try to make this short, and hopefully clarify something...

First off, I don't think you (or anyone else who uses the above approach) is "broken"; such a series of steps as shown above is just "winging it" - having an idea in mind, maybe with an end-goal, but no sense of plan in between, so one step at a time. The only problem with this approach is blind alleys, possibly badly written code, and maybe a large refactoring process in the end. Basically, hacking and bodging a system together - which can be fine for small projects, but can result in a mess in larger projects.

From what I understand about defect driven design, though - the client is left "in the dark" as to where/what/when on the project; they know what they want, but they aren't developing or designing it, all they see is problems, and want them fixed. You (as the developer) on the other hand, fix the problems based on their description, and code the fixes to correct the issues to their "design" that they give you piecemeal...

What I meant about being "broken", though - is that if you were able to do this yourself, to yourself - it would be like having multiple personalities who weren't aware of each other (an outdated concept in psychology, I am led to believe) beyond the confines of the "fence" over which problems and solutions are tossed over (this isn't a very good analogy, by the way). You would have to have such "compartmentalization" of your thoughts, that you (and your other "you") wouldn't be aware of the one fooling/lying/conning the other into giving the answers in the piecemeal approach.

That's what DDD feels like to me, anyhow - like some kind of weird "con job", that might possibly work if the environment of development and needs are busy enough (ie, large corporation where bureaucracy gets in the way) such that doing such a process might actually work, and may result in equal or lesser time spent developing the application, while ultimately delivering a possibly great implementation: one the client actually wanted (because they told you exactly what they wanted each step of the way)...?

:smiley:

cr0sh:
First off, I don't think you (or anyone else who uses the above approach) is "broken";

cr0sh - Personally I quite like the idea of "normal" people considering that Im broken..
Ever since I was a wee lad, I have aspired to the idea of becoming a "boffin" :- the crazy hair/being broken is all part of it!

Joking aside, I do see your point, but I also like to see the lighter side as well.

Seeing as how most people I know consider me crazy for just having an arduino, never mind the things I do with it... I have said sod it, and am now playing up to it as much as I can. We all laugh about it, and I occasionally surprise people by doing something useful with it - they watch tv. Who is broken now???? :smiley:

ghoti:

cr0sh:
First off, I don't think you (or anyone else who uses the above approach) is "broken";

cr0sh - Personally I quite like the idea of "normal" people considering that Im broken..

I've seen "normal", and I don't like it! :smiley: