FloatShield: Possible hardware changes

[PeterChmurciak]

Purpose of this issue is to discuss hardware problems of FloatShield and possible changes or enhancements. The hardware should try to adhere to AutomationShield guidelines https://github.com/gergelytakacs/AutomationShield/issues/19.

[issue-label-bot[bot]]

Issue-Label Bot is automatically applying the label feature_request to this issue, with a confidence of 0.67. Please mark this comment with :thumbsup: or :thumbsdown: to give our bot feedback!

Links: app homepage, dashboard and code for this bot.

[PeterChmurciak]

One of @gergelytakacs issues with the current design is that it's not 3.3V board compatible, as stated in https://github.com/gergelytakacs/AutomationShield/issues/169#issue-461985184.

[PeterChmurciak]

One of my issues is the ball/tube size. The crucial attributes of the ball are its weight and its diameter with regard to the tube diameter. Therefore ideal ball would be made of some light material - cork, cotton, polystyrene or it would be hollow plastic ball - like the ones used in table tennis. And at the same time, it would be of only slightly smaller diameter than the inner tube diameter - that there would be almost no room for horizontal movements of the ball. These balls are made in specific normalised sizes, most often 30 and 40 sometimes 35 milimetres. Currently used balls are 30mm cork ones. Therefore ideal tube inner diameter should be 31 or 36 or 41 based on the ball used, in our case 31/32mm. Unfortunately, the current tube has inner diameter of almost 35mm, "almost" being very important word here - recently I got my hands on cotton balls of 35mm diameter because of my conviction that they would fit, well... they didnt. I also got another plastic ball used for table football which had special size of 34 milimetres, and that one was a perfect fit. The problem then was that it was too heavy for the fan. What I want to say, is that there was not enough thought put into choice of tube/ball size combination, and it is surprisingly harder to find balls of specific diameter than it is to find tube of specific diameter - the tube should have been chosen based on available balls. How much big of an improvement would this change of tube be, I am not sure, I am just pointing it out, that it could improve the ball behaviour. However that would be quite an intrusive change because the tube is the biggest part of the FloatShield body and all the 3D parts were created based on its size.

[gergelytakacs]

It is not a problem to change the tube if you wish to do that. I'd suggest you try to get your hands on alternative tubes (e-bay, any other source) - I can refund the price. Re-printing the top/bottom is also a possibility, you just have to contact Erik M. to print out the pieces.

Thinking about it according to the above comments, I recommend the following course of action:

• I'd consider using the FloatShield (let's call it R1) in its current state and get the most out of the given hardware. The reason for this is, that we have 10 pcs. of it and we should get it to a state that is usable (useful) for the students in the future without re-doing it a lot. Small and not intrusive changes are fine (different bal, "linearizer" etc.) , but focus on software at the moment.
• For hardware changes, In th meantime, I'd completely redesign the thing, let's call this FloatShield R2. This will be "your" bettered version, and we do You may even want to think about making it considerably smaller if necessary. Nobody said it has to be this big, e.g. So if you wish to get your hands dirty, we should start a parallel effort to get a second generation FloatShield designed.

This would be ideal, as HW design takes a lot of trial and error, lots of waiting on orders and while that is done you can work with the current one. (Later there can be switches in the SW to adjust for the versions).

[gergelytakacs]

@PeterChmurciak Shall I look for balls too? (That sounds funny when I type it like that!:)

[gergelytakacs]

@PeterChmurciak This was the first result of my search. Ebay thinks its funny as well.

[gergelytakacs]

Jesus, I'm going to get ads for cock rings now for the next month.

[PeterChmurciak]

@gergelytakacs You can try looking, I have looked mostly on the Slovak/Czech stores. Ball with diameter 33 or 34mm would be ideal, however it also needs to be made of some light material. The internet is surely full of balls, unfortunately most of them are the kind you would not like to get your hands on.

[gergelytakacs]

Moving some info from #44 that will be closed:

• sensor and vent connectors too close together (possible solution - smaller vent connector size fits, for future PCBs might be redesigned as well)
• short-circuited resistor (due to contacts touching usb port, has to be moved on the PCB in future design, for now, duct tape will do)
• Fan connector too close.
• 3.3 V compatibility
• Description of the sensor is missing (silk?)
• Smaller potentiometer (#19) a bit farther away from the fan for easier accesbility.

[gergelytakacs]

@PeterChmurciak

This is more of a long term question: after the identification is done, (see other threads) you / we have to decide how and where to continue. For this we may have to get together to have a short chat. You'll have to see whether you are interested getting your hands dirty by a bit of hardware design (e.g. to create a new revision of Float 2), or just to do a basic upgrade with 3.3 V compatibility, or just to focus on software altogether. etc.

[gergelytakacs]

@PeterChmurciak

Any luck with learning DIP Trace?

[PeterChmurciak]

@gergelytakacs Somewhat yes. For now I have made following changes to the PCB layout:

• To make it 3.3V compatible I have changed the voltage source of the Potentiometer and the VL53L0X sensor from 5V to 3.3V.
• To solve the short-circuit I have repositioned the resistors (R2, R3).

Original layout:

New layout:

If I understand it correctly, we also want to use a smaller potentiometer, specifically CA9MV-10K as mentioned in hardware guidelines, is that right ? Do we have those ? That could save up some space on the board and allow for more repositioning of resistors (possibly the R2 and R3 resistors might be too close right now).

Few questions based on https://github.com/gergelytakacs/AutomationShield/issues/170#issuecomment-512206822, shall we also use smaller vent connector size fits ? What is the Fan too close to ? And how did you mean sensor description ? Currently the sensor connection is labeled as J1 should it be any different ?

[gergelytakacs]

@PeterChmurciak

Great, I see you are getting started!;) I'll try to answer your notes as efficiently as possible:

• Yes, please use the smaller potentiometer, CA9MV-10K. I'll attach a design that uses it, so you can just copy and reuse. We have them physically available in the lab too. Magneto.zip
• Now that the pot is powered by 3.3 V, is compatible with CMOS level boards, but not with TTL level ones (AVR). Solution: you have to connect the 3.3 V source to the AREF pin - then in software tell the AVR boards that the analog reference is external. So basically the software will have to have various parts for board versions (e.g. IFDEF BOARDRELEASE = R2 ).
• The MOSFET should be marked with something else than "C", it is not a capacitor. E.g. you can use "Q" that's usual for transistors and similar components.
• "Description of the sensor is missing (silk?)" - I have absolutely no idea what I wanted back then, lol:) Just ignore it. Maybe I wanted to put there y(k) near the sensor connector, as it was in Opto... Bu since neither the actuator nor the sensor is on the board itself, it does not make sense to label it like that. So, don't worry about this.
• "Sensor and vent connectors" [...] I don't remember the exact reasons why I had a problem with that, maybe it was just too close together for my taste. Inspect that area and decide if you see an issue or not. Maybe just move them a bit further away (in the y-direction)... Again, don't worry about that too much.
• Don't forget that the schematic and PCB views should remain connected and you can synchronize them. I hope you are not working only in the PCB view to make changes. (So that we will have the scheme as well).
• Perform any other change you see fit.

[PeterChmurciak]

@gergelytakacs Specific parts in the PCB schemes are taken from AutomationShield.eli Diptrace library. Is there a way for me to get access to that library ? I could not find it anywhere in the files.

[PeterChmurciak]

@gergelytakacs I believe that Uno schematic block, that has identical layout as the real board itself should be used in this case, like this one:

With GND and A4,A5,SDA,SCL ports somehow differentiated.

Reason for this is that currently, there is only one GND port, while in reality there are three (on UNO) GND ports. In different situations we might want to use different ports, like in https://github.com/gergelytakacs/AutomationShield/issues/170#issuecomment-525464330 - the C1 MOSFET is connected to the second GND port - because it is closer. Same thing with J1 that uses SDA/SCL ports instead of A4/A5, because the path is more straightforward. Currently in the scheme is used block:

When the layout as in https://github.com/gergelytakacs/AutomationShield/issues/170#issuecomment-525464330 is used, and the layout is synchronised with the scheme, the paths to the second GND and to SDA/SCL ports are removed, and want to forcibly use the default GND and A4/A5:

This is caused by the other ports not being defined (not connected with blue line) in block-pattern connection, because there is currently nothing to connect them to:

It could be fixed by creating Uno block that has identical pins as the hardware, so each virtual pin (in scheme) could be connected to its real counterpart (in the board pattern). This solution, while making the scheme block slightly bigger would allow more flexibility in the routing department, as the pins that are closer or in more favorable position to the component could be used, and then synchronising the layout with scheme or using the autorouting tool should work as intended.

I will probably need the AutomationShield.eli library as there is proper board pattern and components that I currently have only copies of. I only hope that it still exists. I can then implement the new Uno block into it. What do you think about that ?

[PeterChmurciak]

@gergelytakacs

Original scheme:

New scheme:

I am not sure about their correctness but these two schemes are equivalent. The new one also uses new arduino block, new-smaller potentiometer and connection 3.3V-AREF. There are also lesser amount of "cables" shown on the new scheme. What do you think about it ? Should I change it somehow (for example show more cables) ?

[PeterChmurciak]

@gergelytakacs I have saved the blocks that were used in files that you and the FloatShield wiki provided me, and modified them to suit my needs.

New layout (top):

New layout (bottom):

This includes new potentiometer, bigger gaps between connectors and 3.3V-AREF connection. (On the back mask - FloatShield v1.1 R1 09/19)

I would like to ask you about this connection (blue line on the second picture), whether it can be realised like this - wider trace (from 3.3V) that goes to potentiometer 100% pin, and out of there thinner trace goes to AREF pin. Is that correct way of doing it ?

Please review both scheme and layout and tell me if you would like to see something done differently.

[gergelytakacs]

Hello there @PeterChmurciak

I will try to be as efficient as possible with my reply:

• Regarding this comment: I have shared my Dropbox containing the entire AutomationShield with you. There is a "common" parts library for the AutomationShield project. The original idea was, that each new part we create will be saved in a custom library for future use.

{...] With GND and A4,A5,SDA,SCL ports somehow differentiated.

You are correct. The original UNO part was fine, but now it grew over us and we need GND's and SDA/SCL pins differentiated. We ran into that problem before, we chose to leave the original (simple) UNO part in the schematic view, then changed routing manually in the board view.

Same thing with J1 that uses SDA/SCL ports instead of A4/A5, because the path is more straightforward.

That is not the only and most important reason. The SDA/SCL ports are compatible across different boards (e.g. Mega, Zero etc.) but the Uno is the only one that has SDA/SCL on the A4/A5. So I'd rather remove the SDA/SCL notes from A4/A5, because that would make our designs Uno specific.

It could be fixed by creating Uno block that has identical pins as the hardware

I think that would be the best course of action. And I would say you should call it "Uno R3 Pinout" so as to not to refer the board itself but the pinout. And use only the default SDA/SCL connectors not A4/A5. After reading the rest of your comments, I think you already did change it around. In that case it would be good if you'd save it in the common library for future designs.

New scheme:

• It looks good to me, but I'd prefer the more cables version and no net ports. I tell you why. For working with the scheme the less cables and net ports are better. But we will have to show your new design eventually (e.g. your thesis, possibly further academic paper) and for that I think the cabled version is preferrable.
• The other think I'd ask is you change the schematic symbol of the MOSFET because it's really disproportionately huge compared to the rest of the components. This is just an aesthetics issue.
• Why are the D7, D8 connections on the sensor jumper active? Are they used in any way? I don't actually think so! Can you please investigate this?

I would like to ask you about this connection (blue line on the second picture), whether it can be realised like this - wider trace (from 3.3V) that goes to potentiometer 100% pin, and out of there thinner trace goes to AREF pin. Is that correct way of doing it ?

The wider traces are used at places, where there are more current to be expected. That is not the case with the potentiometer, so you can change it back to regular trace width. You should inspect ground and voltage traces to and from the fan/MOSFET for trace width, since these carrry a bit more juice.

(On the back mask - FloatShield v1.1 R1 09/19)

Please call it FloatShield R2. You will need to alter code between versions, and it will be easier to refer to it as "no. 2" when using #ifdef-like precompiler definitions:)

Please review both scheme and layout and tell me if you would like to see something done differently.

I stared at both the schematic representation and the trace layout and said everything I could think of above. Check whether D7/D8 even makes sense. What do those connect to on the sensor? Are they needed? (Dont't think so.)

I also recommend to print out the design 1:1 on paper and check it like that...

[PeterChmurciak]

@gergelytakacs

Why are the D7, D8 connections on the sensor jumper active? Are they used in any way? I don't actually think so! Can you please investigate this?

This is interesting question, I did not think much about them, I just assumed that they should be there because they were there before. I have looked into it.

Our sensor looks like this:

• GPIO1 on sensor is connected to D8 on board
• XSHUT on sensor is connected to D7 on board

As I understand it (based on this), they are required when there are more VL53L0X sensors being used. This site provides short description about their additional usage.

In our case, there is only one sensor of this kind being used, and that will probably not change. Therefore usage of those two pins is obsolete. Actually, despite the pathways created on the R1 v1.0 board, there are only 4 cables being used to connect the sensor with the jumper J1 - the D7 and D8 pathways are not used.

To make sure I have tested the sensor using cables directly connected to arduino to confirm that only the 4 first pins are required - VCC, GND, SCL, SDA. That is indeed the case.

You were right, the D7 and D8 connections are not used, and in our case will not be used. I therefore believe that we can safely remove those pathways from the scheme&layout. What do you think?

[gergelytakacs]

@PeterChmurciak

Please remove these connections, they won't be used or necessary.

[PeterChmurciak]

@gergelytakacs

Latest scheme:

And latest layout:

Top:

Botttom:

On the back mask is FloatShield v1.1 R2 09/19, should there be v1.0 instead ? Because it is first version of R2 ? I undersoot it that vx.x would increase when making minor changes to the board, and Rx would increase when doing major changes to the board. But new board will be created probably only when there will be some major changes done - that means Rx will increment, and that means the vx.x will never increment...

Please see if there is something else you dont like, or something that you would like done differently.

[PeterChmurciak]

@gergelytakacs I guess that matter concerning 3D printing should be discussed with @erik1392 ? Do you know about a good way of contacting him ? I have tried contacting him using university email but it is possible that he does not use it as often during summer as during school year.

I would like to change the 3D sensor holder at the top of the tube, as it can move around pretty easily (at least on my unit), and I dont see a duct tape as long term solution. Does Erik (or do you) possibly have the CAD model of current sensor holder ? It might need just minor tweaks.

[erik1392]

@PeterChmurciak sorry I did not respond to your email on Friday, I will print it today. 3D model is downloadable form wiki here, there is the whole assembly in .step and also some .iam (inventor assembly) which is probably useless without separate files for all the parts. The .step file should work just fine.

[gergelytakacs]

If a fan with a hall sensor is used

• What is the amplitude of the signal of the fan, and how to connect electrically to the Arduino?
• What TC will be used on an Uno to count? Timer2? Which pins can be used as counters with Timer2?
• Will be a different (possibly 3 pin connector)
• The lower sensor connector could be 4 pin!
• The MOSFET schematic sign is extra ugly. Please correct.

Will need a components list to buy stuff!!!!

[PeterChmurciak]

@erik1392 could you please provide me with the model name of the new fan you propose to use in R2 ?

[PeterChmurciak]

@gergelytakacs Timer0 is reserved for Uno functions, Sampling library on Uno uses Timer1 so we are left with Timer2. The Timer2 is also responsible for controlling PWM output signals generated by pins 3 (which we use for PWM) and 11. I am not entirely sure whether that could be a problem.

[gergelytakacs]

@PeterChmurciak I'm pretty sure that is an issue though. So we are stuck with Timer 2 in this case that also uses PWM.

So TL;DR: @erik1392 It is a great idea to have a fan with RPM feedback but which counter would we use (on the Uno) to count the signal? Or would this be reserved to other boards than the Uno?

We need to decide if the Fan+RPM is actually doable or not...

[PeterChmurciak]

The Timers responsible for PWM pins based on this article are: Pins 5 and 6: controlled by timer0 Pins 9 and 10: controlled by timer1 Pins 11 and 3: controlled by timer2

So when we use one of those PWM pins, the timer can no longer be used for something else. If we used Timer1 for sampling, Timer2 for counting RPM, we could then use pin 5 or 6 for PWM fan control. Just using PWM created by Timer0 should not compromise any of the Timer0 delay()/millis()/etc. functions. What do you think, is that correct ?

[PeterChmurciak]

Cited from this article:

The Arduino uses Timer 0 internally for the millis() and delay() functions, so be warned that changing the frequency of this timer will cause those functions to be erroneous. Using the PWM outputs is safe if you don't change the frequency, though.

[gergelytakacs]

@PeterChmurciak Nice find, and you are actually right. I've completely forgot about this. They've combined the timing functions with PWM capability! So basically theoretically Timer 0 should be capable of producing both PWM and timing for delay() etc. In this case any sort of PWM should be handled by either pins 5 or 6 (on any future shield).

However mind you that 5 and 6 uses a faster PWM frequency because of this (980 Hz vs 490 Hz). It might change absolutely nothing, or it may make a difference. Can't say right now. Can you test this? E.g. to patch the current FloatShield to work from pin 5 (or 6)? I think using a piece of cable should be fine. Just to be sure.

If you can confirm that nothing changes, then we can use Timer 2 for inputs from the fan. Then the next step would be to find out how the fan signal works at all.

[PeterChmurciak]

@gergelytakacs I have tested at what power level the ball starts to lift from the ground - when using PWM pin 3 the ball starts to lift around 46% of power and when using PWM pin 5 the ball starts to lift around 52% of power - using the PWM from pin 5 moves up the required power level of the fan to lift the ball off the ground by approximately 5%.

To make sure I tried the PID example:

Results are very similliar, in this case slightly better with PWM from pin 5 but that might be a fluke. When taking closer look at the power levels:

Indeed there is approximately 5% power level difference to keep the ball at stable altitude. Not sure how big of a problem this is. What do you think ?

[gergelytakacs]

@PeterChmurciak The results look good, there is no need to worry about anything you wrote. I think we shall safely move the PWM output to no. 5/6 pins.

You may make this change right in the scheme / PCB for R2.

Now please have a look at the way the fan gives the feedback signal. Ask Erik for the type, you can try to contact him through Facebook if he is unresponsive.

[gergelytakacs]

@PeterChmurciak PS: I think he said it's completely the same + the signal, so you may be able to find it on your own.

[erik1392]

@PeterChmurciak @gergelytakacs Sorry for the late response. This is the fan it is exactly the same one but with one extra wire. I also found some basic example, how to read the RPM but the software side won't be sufficient enough for us. The good news is that the hall sensor circuit inside the fan is just connecting the pin to the GND through some transistor so it can work with any voltage.

[erik1392]

I have some 3pin fans at home so I can verify ti next week.

[PeterChmurciak]

@gergelytakacs First part of this article combined with following graph taken from fan specification:

Leads me to belive that this is how the feedback signal looks, where each "step" represents one quarter of a rotation. However I was not able to find out the signal amplitude (on the top of this picture there is +12.0V but I am sceptical about that). In every example of this kind that I have found, the signal cable was connected directly to interrupt pin, using resistor only as a pull up (like in example provided by @erik1392). To make sure we will probably need to test it.

[PeterChmurciak]

@gergelytakacs MOSFET schematic old vs new:

What do you think ?

[gergelytakacs]

@erik1392 So you put any voltage onto the signal pin and it is connected to ground from time to time? That is actually smart. So please do verify it in experiment if you have such a fan available.

@PeterChmurciak Testing it will be the easiest way. If I understand Erik correctly you are supplying a signal to this pin and measuring it's state. The fan circuitry pulls it to gnd.

PS: Yes, the mosfet looks good!;)

PS2: As Erik says, the datasheet is pretty clear on this and he is right. They have a drawing for pin connection in there. You just need to add a resistor.

[erik1392]

@gergelytakacs @PeterChmurciak I have som interesting foundings. It would be very difficult to use a fan with a hall sensor and control the fan with PWM because the power for fan and sensor is cut off and it is impossible to read rpm correctly, I tried even connecting the cap in parallel to the fan. (PWM at 80%) It helped a bit but it drastically changed PWM vs. fan characteristic ( increased the effective value of current) which is not neceserly the bad thing but at low PWM values, ti still made quite an ugly signal at the hall sensor output. (PWM at 15%) So I propose that we use a fan with 4 wire connections, where the fan is connected to power +12V, GND, hall sensor output and PWM input and the RPM controller is inside the fan. We also won´t need the Mosfet on the shield.

I found this one, the same size except it is 4mm toller and should be a bit more powerful in terms of airflow and pressure but it should draw less current.

I also tested this type of fan and rpm measurement works correctly. (hall sensor output with 4wire fan)

(rpm and PWM sent to the fan)

[PeterChmurciak]

@erik1392 Interesting. It seems like the speed of the fan with 3 wire connections was not meant to be regulated through PWM ?

I like the idea of using 4 wire fan that would remove the need of using MOSFET, if something can be done simpler and better, why not. It would also save up space on PCB. On the other hand, will not the PCB become too empty ?... Maybe I am just used to sight of it being full of components.

[gergelytakacs]

@erik1392 @PeterChmurciak

Erik, thank you very much for your extensive research into the fan. If I understand it correctly, the power to the hall circuit is cut off with each "0" of the PWM signal? So that means, that it should be controlled by an analog signal?

To me the 4 wire solution sounds okay. I am not bothered by the lack of MOSFET actually. We should try it! Peter - can you maybe order one of these fans for testing? I will order anything more expensive you need, but the thing is it is way too complicated do the paperwork for orders (not worth it if they are small).

[erik1392]

@gergelytakacs yes because we are interrupting connection to GND with the MOSFET, it may work if we use the high side MOSFET but I haven't tested it. It looks like a PC motherboard uses some kind of linear voltage regulators to control fan rpm.

@PeterChmurciak just thing I noticed, I would advise connecting all GND pins on the shield together and run the GND trace for Fan connector from that two pins at Power header. Right now the fan GND is connected only to GND pin at digital I/O header and I am not sure how much current can traces connecting that pin withstand.

[gergelytakacs]

@erik1392 Please try to test it with a high-side MOSFET too, just out of curiosity.

@PeterChmurciak I agree w/ Erik on connecting the ground connection. Also, please try to order a single fan for testing, if you can!;)

[PeterChmurciak]

@gergelytakacs Alright, I have ordered the fan that @erik1392 has proposed to use. It will be delivered probably during next week so when it does, I will try it out.

@erik1392 interesting idea with the GND pins, I shall do that.

[gergelytakacs]

@PeterChmurciak Awesome, thanks for the heads up! (see my mail for additional info)

[PeterChmurciak]

@gergelytakacs The latest scheme:

And corresponding layout:

With J1 being the I2C sensor jumper and J2 being the 4 wire fan jumper. Last pin of the fan header will be connected to the pin responsible for counting RPMs. I am currently not sure which pin can be used for that with Timer2.

[erik1392]

@PeterChmurciak nice work but the fan header has wrongpin order. Pin 3 is hall sensor and 4 is PWM input.

[gergelytakacs]

@PeterChmurciak

Haven't you selected a fan that has both PWM input and signal output? Because in that case you will need 4 wires into the connector. So I agree with @erik1392 that something seems to be amiss. Also, has the fan arrived and have you tested it?

[PeterChmurciak]

@erik1392 @gergelytakacs Indeed I have selected the 4 wire fan. I did not know the order of the pins at the time of creating the layout so I just randomly connected the 3rd pin to PWM and left the 4th pin unconnected. Other reason of not connecting the 4th pin was that I was/and still am not sure what pin should it be connected to - using which pin will be the counting realised. Can you please advise me with that ?

The fan has arrived yesterday but I did not test it yet. Will do that tomorrow.

[PeterChmurciak]

@gergelytakacs I have began testing of the new fan. It has 4 wires (from left to right) black, blue, yellow, red. Their function is represented by their colour:

BLACK - GND BLUE - PWM signal YELLOW - signal from Hall sensor RED - VCC (+12V)

The cables are thinner than the ones on the previous fan and are separate - do not stick together, so connecting them into the board in the same order as they come out of the fan is not necessarry. I guess I will still move the GND connection into the last pin of the J2 header to keep their order.

The new fan is more powerful but also lot louder than the previous one (at the 200 PWM sounds like a jet taking off), thankfully our working levels when balancing the ball are not that high. It also has a faster reaction time for PWM change - because of that the current PID example does not work with it - the constants for R2 will have to be different.

The Hall sensor (YELLOW) wire works as we expected - the INPUT pin the wire is connected to on the board needs to be pulled up using external or arduino-internal pull-up resistor (to 3.3V/5V), and through the YELLOW wire the INPUT pin state is being pulled down to zero. What do you think should we use external resistor or built-in resistor for this ?

Currently working on getting the RPM.