Widget Weight Counter using HX711 and LED Display – Feasibility Study

@davee, Well done my friend...and no, I don't mind at all that you have a Simpler solution, simple is always better...!

regards,

LouisR

Dave, All I can say is, WOW! The time and effort you have invested here, with no compensation on the horizon, (that is, until I figure out how to send you a case of your favorite "whatever",lol), is almost shocking. I'm feeling like "Thanks" doesn't really say enough, but here's 10 more, and that's just for today. I can't comment on any of the technical info you provided, since it is all above my (current) pay grade, but I do want to mention that I'm a little apprehensive about what lies ahead with regards to (my part of) completion of the project. In my minds eye, I see a situation similar to one of those classic movies where the pilot of the plane is sick or dead, and a passenger has to land the plane, with instructions over the radio. (Well, not that bad, since I do have limited experience working on electrical things, including detailed wiring and soldering, but nothing to this level). So, it will be more like they found a passenger who has flown a two seater Piper Cub, but will now land the 747. I'm definitely up for it, and I love a challenge, but I foresee quite a bit of (long distance) hand-holding, so I'm just putting that out there. For example, in your Phase 1:Microcontroller section, you say that Louis' suggestion (thanks Louis) of the TLC5916 would be a good choice for someone who is experienced in handling shift registers, programming for brightness, etc, are things I will be doing for the first time. Also, the lack of (required?) test equipment is mentioned, and yes, I am limited to two (count em') pieces of equipment, (Fluke 117, and 325), unless of course we are going to count my trusty old Simpson 260, but that's from another life. Lastly, I do have a couple of operational questions, and please forgive me if I'm putting the cart before the horse, considering that you're still working hard at just getting a prototype up and running. The questions I have concern the ongoing operation of the system, which, in a perfect world, would be able to run continuously 24/7/365 once both systems are energized, and the initial weight calibrations are done. Once the display(s) are showing a number from zero through nine, would I just be able to "slowly back out of the room" and that's that? (I just remembered something that I may not have mentioned before. With regard to the number of widgets in the pan, there are times when the number of widgets will be reduced, usually by one, but sometimes two, by manually removing them from the pan. Will the system be able to be coded so as to account for the times that widgets are both increased AND decreased? Ideally, the readout will always be "live", showing the current count, whether widgets are dumped in or pulled out. Sorry if I failed to mention that before!) Finally, with regard to continuous operation, the readouts won't actually be used 24/7, but I only mentioned that because I'm concerned that powering down the system will lead to having to reset and recalibrate, which, because of the mounting situation, is just a pita. I'm not sure where you stand on the matter of these microprocessor systems running all the time. Another matter is that with so many storms here in the summer, there will be power losses, which I assume would lead to restarts/boots. In an effort to possibly eliminate those power glitches, I have researched UPS units that are available for not much, and would(?) eliminate the power loss issue.  Appreciatively, Bill   

Hi Bill @billinfl,

   Thanks for your kind thoughts and appreciation.

  You have just written quite a lot, so I might not have spotted all the questions, and now is not a good moment to dissect every syllable, so let's just start with a little of the 'overall picture', and, if necessary, think about the details later.

Whenever you start with a project like this, you are likely to go through some ups and downs. The basic principles, etc. of the project are pretty simple, so with a 'favourable wind', I think you should be able to put a rough prototype together and make it demonstrate the basic idea. Of course, you will probably have to fix a few basic bugs on the way.

-----------

The question that is harder, is will there be any 'niggles', and if they are, will you be able to fix them all? Sorry, I don't have a guaranteed answer to that.

This is when you find that the first working prototype is less than 10% of a polished product. And I would suggest that at best, I am only halfway to a working bench level prototype. However, I am hoping that 'halfway' is enough for you to get at least a bench system that shows the right number of widgets on the display, 'most of the time'.

I simply haven't got a mechanical set up + load cell that is good enough to reproduce results with the accuracy you need, but I think you have, so I am leaving that side to you, with my fingers crossed to wish you good luck.

I am also concerned that I have seen slow drift of reported weight with time. I am not clear if that is the lousy load cell/mechanics, or the HX711 not playing nicely, or both? I could spend some time and money diagnosing it, but for now, I am passing on my findings in a 'present state of the art' form for you to try, if you want to.

I should say, even in a more commercial research and development operation, the above experience is fairly typical. Of course most companies have a well-established 'design base' and experience, so a substantial part of their 'R&D' can be a tweak and improve operation, which is somewhat different.

---------------------

So, assuming you are still up for the challenge, even though you have just realised that 1 lap race is actually 10 laps long ...

I have detailed a number of 'phases'. I suggest you essentially try to 'reproduce' them, albeit you can use a large LED from the beginning, so Phase 2 (higher voltage LED test) becomes redundant, and I presume from your comments and photos, you have a 'sensible' load cell and bench mounting, so that is already to use.

There may be other points, that you need to adapt the steps to your situation ... use some common sense.

I have suggested you look to the ULN2003 for driving the display, as I had some in the spares box, and I have actually tried it. Sometimes, things look better on the data sheet, than in practice! Louis (@inst-tech) and I can both see alternatives, some of which are 'smarter', but few look 'easier', so I hoping it is a 'safe' bet. (Famous last words ..? 🤔 🤔 )

The microcontroller board has also been discussed before. The board you have bought has lots of bells and whistles, but this application really just needs 9 GPIO pins that can be driven without worrying about other 'clever' stuff on the development board.

It is possible, maybe probable, that the board you have will do the job fine, but I can't really be sure without buying one and trying it, which I am reluctant to do, as I don't have any plans that would need such a board afterwards. So, if you want a simple-ish life, I would suggest you look for a more basic board. I had an ESP32-S3 dev board to hand, but as I discussed previously, there are alternates, which are not too financially painful. Otherwise, you need to figure out which pins will do the job, using the boards you already have.

You will also need a power source with a high enough voltage to drive the LED. If all else fails, 7-8 AA alkaline cells in series should do it for some initial experiments. Many people will have a variable bench supply, but I can understand that you may not ready for that outlay, etc. yet. (I think you may need to buy some resistors as well - a bargain pack of 1/4Watt various values for a few dollars, has been my approach to get started.)

From your previous comments, I assume you already have an HX711 board to try.

-----------------------------

So perhaps you are attempting to fly a 747 on a Private Pilot's Licence, but 747 pilot's had to start somewhere... hopefully your landings will be reasonably safe, and not too scary!

I hope you will be able to put something together which works without recalibrating all the time, but frankly, that is part of the latter 90% of development that is still 'pie in the sky' at the moment.

I think it is possible, that from time-to-time, it will be necessary to empty the pan, and cycle the power, so that it 'reboots' and 're-zeroes' everything. That should only take a few seconds. Whether this is needed every few minutes or a couple of times a year, I have no idea.

Other questions you mention, are also largely in the '90%' development refinement process, including:

All logic systems are susceptible to 'upsets' from various sources and mechanisms, including cosmic rays. For safety critical, and the like, applications, there are methods of minimising the impact, but I would not advise a beginner to get involved with them, as although some of the principles are fairly simple, implementing them is an art form of its own.

UPS is a little different, but I would start by asking, is it necessary? If the power fails, then in many cases, other supporting things also 'grind to a halt', so there is no need to count widgets. When the power is restored, I would hope it would resume 'normal service' within a few seconds. (Probably need to ensure pan is empty on restart.) Things like this, are usually best left to a later stage, but don't expect miracles to vanquish any really tricky problems.

I don't see why it should mind you adding or removing widgets ... remember it will take a few moments to 'settle' between each change. Again, this is part of the 90%, and will be affected by mechanics, load cell manufacture and so on.

---------------

Obviously, I don't know what your application is, but you should consider how you check that the system is working, and what is the consequence of it 'losing the plot' and reporting the wrong answer. Remember, all machines will fail, usually without warning. All of this has assumed that this is a social/hobby development, with no serious consequences, (beyond your personal frustration). I do not take any responsibility for ensuring the safety, financial, etc. consequences of any failures and so on. They are entirely your responsibility.

-------------

Hope this helps .... please feel free to ask further queries or remind me to address those I missed.

Best wishes and good luck, Dave

Hi Dave. Thanks for another helpful reply. I'm a little swamped with other stuff today and possibly tomorrow, so I'll have a more complete reply, and of course, more questions, soon. For now, just a couple things. First, I just want to address what you said about not taking any responsibility for any consequences that may occur with this project. You are wise to state that, but I can assure you that the repercussions of any failure in any phase of this project are zero. Well, except for perhaps me having to take something for my headache when something glitches or smokes out completely. The purpose of this whole project is to enhance a hobby I have, and that's it. It's not for business, or any financial gain or anything other than fun. So, no worries there.

With regard to the Wheatstone bridge issues you have been experiencing, I have been blessed ,so far, with very steady weight readings on my 16x2 lcd. Even when I've left some widgets in the pan for hours, the readings don't change. When I weigh different ones, (they have slight differences) they also always read the same. The load cell I'm using is a bar type, 5kg, about half the length of a large cigar. 

Also, I do intend to use my Uno r-4's for the project, and there does seem to be enough pins. If not, I have read that I can increase the pin count by hooking up my LCD screen with an I2C module, so it uses only 4 wires, but you probably knew that. Am I correct to assume that the final version of the counter will need to have an LCD screen, or can resets just be accomplished with reset button(s) on the board?

Lastly, the ULN2003 driver chips seem to have several versions, (at least on the mouser electronics site), and I'm wondering if I need a specific one when I order?

Thanks again.Talk soon, Bill

Hi Bill @billinfl,

   Thanks for the reassurance on liability, etc. Making a unit that is 'totally reliable', is really hard (arguably impossible?) and expensive; making one that works most of the time, is a much more realistic aim. I am sure you will have a couple of 'bad moments', but hopefully nothing too painful or expensive.

Pleased to hear your weighing system so far looks more stable. The rather nasty looking load cell I have, is certainly responsible for some of the issues, but I am less clear if there are any others. If I had a project for myself in mind, I would have replaced it already.

I hope you are right about there being enough pins on your UNO r-4. I suspect you are right, but a quick look at the data sheet suggested quite a number were already connected. In some cases, this is ok, but you have to understand what effect two things connected to the same GPIO will have. You won't come to any harm if you accidentally end up with two things connected to the same GPIO, but it might be confusing if you do get an overlap, and unfortunately I can't test it for myself, without buying one, so it is harder to give advice, though I'll take a best guess, based on what I can see on the Net.

As for reset, etc. you have some choices. The code I provided in all cases will boot from power up, so one 'extreme', is to cycle the power on and off.

For convenience, on my breadboard, I also had a little push-to-make button, that momentarily connected the reset pin of the ESP to ground. When the button is released, the processor then boots in the same way as at power up. Even though I could have used the reset button on the dev board, I added another one, because it was easier to push. This will also be true if you put the electronics in a box, etc.

You may wish to add an LCD panel, etc., but if you follow through the sequence of phases, you will realise the only 'data' displayed, was via the Arduino IDE Serial Monitor, as part of the testing and set up.

By the time you have the final phase 'working', the Serial Monitor is no longer required. The calibration factor between HX711 numbers and widget count is already 'hard coded' into the program code, via a #define; and the 'zeroing' (tare), automatically happens when the program boots. You just have to make sure the pan is empty every time the program boots. (You probably have some digital kitchen scales that are similar in action.)

Of course, you may want to have a different user interface for your final product. That is your choice, but I would start with my 'phases' for your first prototype, and gradually make it smarter, etc.

I see what you mean about the ULN2003 having variants ... two pages full! Your application isn't that demanding, so probably anyone would be fine, but I thought you might find an 'old skool' DIL package version, with pins on 0.1" spacing easier to work with, so something like Texas Instrument ULN2003AN should probably be fine. (Or, if you prefer surface mount, you have plenty to choose from!)

( https://www.mouser.co.uk/ProductDetail/Texas-Instruments/ULN2003AN?qs=FOlmdCx%252BAA1wYQ1G8c8hpQ%3D%3D)

Of course, Mouser will ensure you get a 'genuine' badged product, which is a reassuring and would be my approach for a professional development, but (for me at least), small orders are expensive on delivery.

Depending on the size of your total order, You may find some cheap alternates on eBay, AliExpress, etc. for less money, albeit higher risk on quality, etc. (The chip I used came in a 'bargain box' of about 15 different chip types, 4-5 of each, which is why it was in my 'junk store'!) The choices and risks are all yours.

----------

Hope that helps ... good luck and best wishes, Dave

@davee Hi Dave, After some delays, I'm finally back on the counter project. So far, it's good news, I think. The 2003 seems to be a good recommendation, so thanks for that. First off, I want to mention that even though I ordered the 2003AN as per your last advice, what I received is a ULN2003APG.(Toshiba?).

 I was going to send them back (pack of 10), but I was excited about getting started, so I forged ahead, which has now yielded some good(?) intel, which I have provided in the photo and schematic below. I am sorry for the crude drawing, but I have no experience with creating diagrams using my computer, like the ones you made, and I just wanted to get this info to you to look at.

As you can see from the drawing, I chose to use batteries to trigger the 7 switches on the IC. I just didn't feel comfortable hooking up the Arduino as of yet. (baby steps). Also, the connections that finally worked for me were slightly different than your drawing. Specifically, the lack of any connection to pin 9. I researched connections that others have used in the past, and what I found mostly were folks that only used pin 9 when they were switching inductive/magnetic loads such as relays, solenoids and motors, to protect the chip from any leftover energy in those devices. Otherwise, pin 9 was unused. So far, all 7 segments have been burning at an acceptable brightness for a couple days on the bench, with nothing getting the slightest bit warm to touch. 

I had such trouble with the pinouts for the LED. The wiring on my drawing is completely different from what is shown on the data sheet. Sheesh!

I tried to have my drawing match the photo, complete with the breadboards in bold marker, and the wire colors matching the ones used from board to board. The voltage, resistance and current measurements are circled in light blue, and please know that I'm more than happy to make whatever additional readings if you would like to see more. 

Thanks Dave!

Hi Bill @billinfl,

   Good to see you have made some progress.

  The ULN2003 is one of those 'ubiquitous' chip designs that lots of companies seem to have copied and adapted. If you compare the different data sheets carefully, you will see small differences, such as the maximum voltage they will tolerate, but for applications like yours, where the maximum voltage (12-15V) and currents are modest, I doubt if any of the variations will make any difference.

As you say, the main reason for connection to pin 9 occurs for reactive loads, like relay coils. Personally, I would still connect it to the LED common anode power (+12V line). It may not appear to achieve much, but I think the chip designer would have expected it to be connected, and I can't be 100% sure that the chip designer didn't make any decisions that depend upon it. At worst, connecting it is a small waste of time, as it shouldn't do any harm.

-----------

It looks like your LED current is around 8mA per segment, which should be fine, if the brightness is sufficient. If you need some more brightness, obviously (according to the LED data sheet)  you could reduce the value of the 470 Ohm resistors. When you come to wire up the final thing, I would make it so you can swap those resistors, with minimal disruption, as a last minute 'tweaking' job. But, hopefully, you will not need to change them. Lower current should mean less stress, better reliability, etc.

-------------------

The pin numbering on the seven segment displays does seem to be chaotic ... luckily, you seem to have sussed it out. I was more fortunate, the small display digit I had matched your data sheet in this respect!

-----------

You don't seem to have asked any questions, so I am not sure if you were expecting me to say any more at this point.

So for now, I offer my congratulations in getting this far, and hope you can continue to make progress.

If you have any questions, then please feel free to ask them. I offer no guarantees, but I'll do what I can.

I strongly recommend you sketch out the wiring you intend to use, before connecting the HA711 part and the Arduino part. And feel free to post it here, to see if it prompts any useful comments. Whilst I sometimes use CAD systems, this is not a requirement ... pens and pencils are fine, as you have illustrated above.

Good luck, Dave

@davee Hi Dave. Thanks for your reply and continued support. I have successfully connected my Arduino Uno r-4 to the 2003 APG chip. (the battery pack is no longer needed). The Uno doesn't seem to have any problem lighting each segment to an acceptable brightness without any parts getting even slightly warm. Please note that I have upgraded the breadboard wiring and the drawing to reflect the proper order of the LED segments from A-G going from top to bottom.(they were random before). I do seem to have a problem, which I have a couple questions about. In an effort to try my first ever experiment with coding, I found a sketch online that would simply count from 0 to 9 in order with a one second interval between each number change. Trouble is, although all digits do light, and change each second, they never make any number, only random nonsense combinations of segments. Can you tell from the sketch I provided what the problem is? I am mindful that the sketch doesn't account for me going through the ic chip, and I'm not sure if that could be the issue. I have tried to troubleshoot this issue, by reversing the order of the pins from the code, but same outcome. Although I'm aware that I could just move on with the project and ignore the random stuff I'm getting, but I feel strongly that if I can't get the display to simply count from 0-10, it spells trouble for more the advanced work that lies ahead. Thanks. Bill

better shot of sketch

@billinfl 

You need to specify the pin that powers the digit when it's being displayed. You've only got one digit but you haven't specified any digit pin in the digitPins array.

Hi Bill @billinfl,

  Well done for your achievements!

   I totally agree, you need to get the basic digits 0-9 working, before moving on.

  I notice you have selected a library, which is fine, although it is designed for more complicated cases, including more than 1 digit, so you have a bit more complexity, and something of 'magic' code that it is more difficult to examine.

----------------

BTW You may notice. I provided you with a function that I think did all you needed, i.e. call with a number, and lit the segments, where all of the 'code' was on screen. Essentially, it was an array, which for each digit, it had a 1 if the segment is lit, and a 0 for the segment to be dark. Thus, for different wiring, you just had to swap the 1 and 0s to get the right pattern. I also included a test function to individually identify the segments, as I found it a pain to do. But you have chosen a different path, so let's see if we can make it work.

--------

Anyway, assuming you want to press on with the library, then I would first simplify the test so that it only shows 1 value continuously, and get that digit correct, before moving on. (You can revert it to the 1 second counting test later.)

Note, I am making these instructions up from imagination, which may go wrong ... but let's see if you can figure it out, and report back when/if you get stuck.

----------

Simplify the code inside function loop, to something like.

sevseg.setNumber(8);
sevseg.refreshDisplay();
delay(1000);

Which means it is continuously requesting it to show an '8'.

Hopefully, all 7 segments will be lit, as it doesn't matter if they are swapped over.

If there are less than 7 lit, you need to figure out why. Unfortunately, I don't have the UNO you are using, so it is not easy for me to test.

Don't move on till you get this working, as each next step relies on the prevous ones.

--------------

When you have all 7 segments lighting, with '8' requested, change the 8 to a 1, in the programme and recompile, etc.

With luck, this version will light two segments, but maybe the wrong ones!

You then have a choice of swapping the wires coming into the ULN2003, to choose the right segments, or of swapping the order of the digits in the segmentPins declaration of the programme. Personally, as you have a breadboard, I would swap the wires.

--

When you have a 1 showing on the display, then you should be driving segments B and C, but they might be the wrong way round!

You might find the table below helpful, which is from

https://www.electronics-tutorials.ws/combination/comb_6.html

Note that 1 requires segments B and C to be lit, but 2 lights B but not C.

So change the number requested in the programme to 2, and once again recompile, etc.

From the table, you can see 2 requires 5 segments to be lit, and hopefully you have 5 lit, but probably the wrong 5!!

Initially, just look at segments B and C. If B is lit and C is unlit, then you got B and C correct. But if B is unlit and C is lit, then swap the wires driving B and C.

You should now have B and C correctly wired. Hence, make a note that you should not change these again!!

For now, don't worry that it doesn't look like a '2'. You will need to come back to '2' later, but it is easier to do '7' first, because it only needs on new segment to be correct -- read on...

---------------------

Change the requested number in the program from 2 to 7, and recompile etc.

Consulting the table, 7 requires segments A, B and C. Hopefully, B and C are lit, plus one other segment, but probably not A.

So change the wiring, so that A is also lit, remembering not to change the wiring to B and C.

You should now have 7 on the display, with three segments A, B and C correctly wired.

Add A to the list of segments (B & C) not to change

----------------------

Continue this process, noting it is helpful to look at the table to try to choose a new digit which only has one 'new' segment to find, though this is not always possible. The next digit I would choose would be 4, which unfortunately requires two new segments, F & G, but that is better than some of the others!

Change the wiring (not touching Segments A, B and C), so that it displays a 4.

However, remember F and G may be the wrong way round, so do the same trick hat was used to get segments B & C the right way round. Choose a number that only lights one of F & G. 3 looks like a good choice.

-----------------------

Continue this overall process until you have tested it for all of the digits 0 to 9.

---------------------

When you have got all seven segments wired correctly, revert the program to the form you listed on the screen picture above, and hopefully it will now count through as you would wish!!

--------------

Good luck ... let me know how you get on!!

Best wishes, Dave

Hi @will ( & @billinfl )

Thanks Will, for pointing out another problem ... I was assuming the wiring and the segment declaration order were muddled.

The segment declaration also includes a pin for the not needed or connected, decimal point ... but the hardware driver is only 7-segment. I wasn't sure if the library insisted on this, so I haven't discussed that.

Best wishes, Dave

@will Thanks much Will, for your suggestion. Because I'm a newcomer to making changes to a sketch, (my only experience with changes so far have been to change the delay times between number flashes), I will, embarrassingly, have to hold off on trying your idea for two reasons. One, I'm not sure where exactly (on what line and between which brackets) the digitPins array is. Also, if I haven't specified any digit pins, as you pointed out, I don't get why I'm still getting all seven segments to light, (however wrong their order is). For instance, I have noticed that the first thing that happens when I press the reset button on the Uno is that (I guess as a test for all segments), every segment lights up (showing the number "8"), and then each number is supposed to show up in order from there. I have also noticed that when it gets to "9", the next number is not the "test" above, but rather a zero, with segment "g" dark. So it just keeps running from zero to 9 till you stop it. Lastly, I'm confused that the person who posted the sketch that I'm using, the one I have posted, works for him (or her) without any changes to the sketch. 

One last thing: I have noticed, for the first time just before I'm writing this, that the numbers ARE going in sequence, but the segments that are dark are the ones that are supposed to be lit for each number. (Please see the post I'm about to make to Dave for more details.

I appreciate your help, and hope that my apprehension doesn't come off the wrong way.

Thanks again, Bill

@davee Hi Dave, Thanks. Before I scrub in to today's efforts by trying your suggestions, I need to mention that the "random" behavior of the segments is not really that random after all. I am feeling kind of foolish for not noticing this before, as I did spend a couple of hours straight swapping out wires yesterday to try and correct things, (until heroin strength Tylenol was needed,lol), I never noticed what was happening. So, as you may have already read in my response to Wills' post, the LED is in fact displaying the numbers in order, except for the fact that each time a number comes up, the segments that are dark represent the number actually needing to be shown/lit up! Talk about "out of phase"! You will probably not be surprised to hear that not only am I  flummoxed as to why this is happening, I'm unclear whether I should be looking at sketch changes, or breadboard changes, (or changes in my choice of hobby) to correct this situation. I didn't want to proceed with anything until I told you about my ah-ha moment. Now, where did I put that white flag? Bill