Flowcode Support Board

Hi

I have need to record Lux levels over the course of a day to obtain data for further analysis. Whilst just using a LDR and resistor combination would be a simple solution a ton of time would be wasted in calibration with most likely the hassle of look up tables too.

Noticing the BH1750FVI as a component, this looked to be an ideal way to simplify things as it provides a "Lux" output. Woo-hoo less work for me

I did find a minor bug with it, but Medelec35 quickly sorted that out (as usual) so again many thanks to him for his help.

Flowcode Simulation allowed me to test without any hardware which is a huge plus, so I had code ready to go when I took delivery of my sensors (mine are https://www.amazon.co.uk/gp/product/B07 ... UTF8&psc=1 ). Time now to go to the Evil Lab for some testing.

Up in my Ivory Tower I'm about three or four metres away from the skylights which provide enough natural light during the day for pretty much all activities including that taking place at ground level. As an aside, yesterday we had heavy, heavy rainfall all day and a PV panel, standing vertically and definitely not pointing to any light source, was still giving an output in excess of 14v.

I had a light meter with me that gives a Lux output. Whilst it isn't calibrated (possibly obtained from Maplin a decade or so ago) it wasn't too far away when I compared it with a photographer friend's light meter. Twenty quid versus hundreds..... hmm... no contest for my extremely modest needs.

With the sensor plugged into some breadboard and jumper'd to an EB006 Programmer / Combo board I downloaded the code. I set the light meter sensor as close as I could without casting shadows on the board as best I could, and I did appreciate and expect some differences not least due to the physical differences between the sensors. Bare board versus purpose case.

I have to say I was extremely surprised and impressed. Both readings were within a few digits of each other (610 on meter vs 607 on sensor). Any movement I made nearby would create a change in value that registered on both devices (I have four skylights surrounding bench). Taking my code loop delays into consideration etc I did think that the meter settled quicker than sensor but nothing of real note.

Moving meter / sensor closer / further apart did make quite noticeable differences. A cm or two could make a difference in readings of 40 Lux but of course I am part of the equation too and I'm not exactly static. However whatever the difference it remained consistent as I tested. With a difference of three Lux between them whilst just lying on the bench I shone a torch on them. Both increased from around 615 to around 1074 again maintaining the original difference between them.

For my needs this is more than accurate enough and FC definitely saved me a lot of time by allowing me to automate my capture.

Purely by coincidence another project came around that would be another great use of the sensor. A friend lives in a listed building so you cannot do anything at all (pretty much). They wanted some internal lights to come on in public areas if it got too dark during the day. Those that are familiar with these types of buildings know the problems faced. It isn't as simple as you might initially think. One possible solution is to use this sensor as a free standing remote, possibly linked via RF. Having everything "sleep", possibly waking up every ten or fifteen minutes and making a decision, would most likely give a battery life of many, many months.

Regards

Hi Chipfreyer!

When I saw you have tested this sensor I get curious. I have bougth a couble of these same as yours, and now I test it on a Arduino uno. But I am not able to get i work show 0 all the time, but work in simulation
Are you so kind you will share your program or have a look at my test and maybe see what I do wrong, please.
Br jorgen

Hi Jorgen

I will be in my Evil Lab tomorrow and will test with an Uno. My post used a PIC16F1939 with hardware (I think, but I've been in pub today ) and worked fine.

Nothing special in my code, really just as basic as it gets. Pretty much as yours however when printing I used Unsigned but that is trivial.

Medelec35 did update component so please ensure you have updated your components to latest too.

I honestly thought I'd need to create a chart/graph plotting light meter vs sensor but was genuinely surprised that the delta was so insignificant. No need to create at all.

Further to this I have been asked to monitor "light" during the day.. Hmmm... seriously? Define light..... Well us geeks would now be fighting amongst ourselves depending upon which part of the spectrum we care about.. In this instance I was asked to monitor Lux to PV cell output....

Wonderful.... Where should I start without insulting the question.. and losing client.....?

Depending on the paper you read, and I'm excluding WiKi/Google/whatever etc, the conversion factors are woefully inadequate ranging from "x" to "x times three or four"... Hmm..so 2 x 2 could equal 4 / 6 / 8 upon paper....

I settled on work done by Michael, Johnston and Moreno, which gives an engineering "rule of thumb" of 120. Read here if you are interested

https://www.extrica.com/article/21667

Hopefully I will use the component to measure Lux throughout the day and using the rule-of-thumb as above convert to Sun's.

Keen to compare sensor/conversion against real world PV output, and I may document if of interest.

Regards

Hi Chipfeyer!

Thank you for reply and hope you are ok after the pub visit
My FC is full update, check everytime I start FC
Very interesting link, see you have some experience with measure ligth.

Meanwhile I made some reseach (Google) I see now that the adress pin is depending hi or low as:

ADD pin floating or connected to GND → address: 0x23
ADD pin connected to VCC → address: 0x5C

Ok I suppose that FLowcode is avare of this as you see I use an I2c display, communication on pin C4 and C5 the dedicated pin for serial on arduino. To be sure that the BH 1750 "talt correct" with serial communication, I change my display to softwaremode and use Bport for this, working and change the BH1750 to Channel1 port, but still no data comming out. Also change the Addr pin to H/L no difference.

I also see that some are using 5V other 3,3V https://create.arduino.cc/projecthub/in ... ect-640075 I tryed both.
I bougth these and they seemed to can run on 5V

Look forward to hear from you.

Br Jorgen

Hi Jorgen.
Have you got the BH1750 IC that will require 1K to 4k7 pull up resistors on the data and clock lines or the module that includes the pull-up resistors?
What you could try is the I2C address sniffer found on the Wiki
That will test if there is communication between the sensor and microcontroller and it will give you the correct address.

Hi Martin!

Thank you. I suppose it have build in pullup resistor, it is a board. https://www.ebay.de/itm/252725768417 . When I measure with scope the output is High and data is low. I Will test with the sniffer, good suggest, I have to wait until tomorrow, unfortunately not home today.

Maybe you can tell me already now, what is the adress now in Fc If I choose hi/ low in the config, and why os is it not possible to change the adress
like in other I2C devices?

Would also be nice with an exambles in wiki

Br Jorgen

The address sniffer is just used to detect an address, which would mean the BH1750 IC is being detected.
You don't need to know the actual address for setting the properties
as you only need to select if the slave address pin is connected to VCC = high or GND = low.
If comparing the address found on the sniffer with the address stated on the datasheet which is: Using windows calculator and address pin is connected to GND for example. the address seen on the sniffer results should be:

jgu1 wrote: ↑

Sat Nov 12, 2022 10:14 am

Maybe you can tell me already now, what is the adress now in Fc If I choose hi/ low in the config, and why os is it not possible to change the adress
like in other I2C devices?

It is more friendly for the user if they select if the address pin is at VCC = High or GND = Low.
That is less work than looking up the datasheet to determine what the address should be, then selecting the correct address.

Hi Jorgen

The modules, or mine at least have two addresses, 0x5C and 0x23 depending on Address pin High/Low. FC default is Low.

I connected a Nano and ran the code I previously used on the PIC after changing target. This time I had an I2C display too, sharing the Ch1 pins.

Display showed a constant zero.
Changed Display to Software and moved the pins. Display continued to display zero
Swapped sensor and display over so that sensor now on Software pins, display on Ch1
Display continued to show zero...

Are we having fun yet...??

Downloaded Martin's sniffer (a very cool tool).

With each component inserted in turn to Ch1 it successfully detected both the sensor and the display, returning associated addresses (0x23 for sensor). With both inserted / connected to Ch1 they were both detected.
Are we having fun now ?

I think we can rule out I2C communications......... Incidentally my boards don't need Pull-Ups and Address is held Low without connection.

Now, I cannot explain the following....

I was using the ReadMeasurement Macro, same as you, and this works fine with my PIC but not on Nano. I changed to OneTimeMeasurement and it then worked on the Nano.... Hmmm.... you would be forgiven for thinking a problem with the ReadMeasurement Macro. I changed back to ReadMeasurement and it then worked....

Cycling power brought things to a halt. Display returned zero.

Changing to OneTimeMeasurement brought the readings back and cycling power had no effect. Readings were returned.

I admit to knowing little about the Arduino family so cannot comment if we are doing something stupid.

One for Martin and the team I think

Regards

EDIT..
PS
I couldn't find my Uno but I think the Nano I used was displaying same problems you faced. If I find it I'll try with it too.

Hi both!

@ chipfreyr, you did all the work but anyway I try to copy your ideas and perform your test, with Martin´s adress sniffer also and change from continuos to One time measurement, yes I get one value, same result as yours. It look like there is a bug in the macro.

@ martin. I also use your I2C adress sniffer, good tool use it many time. I also understand and see the idea with the hi/low adresss.
Concerning the Continuos Measurement will you have a look on this macro, pls.

Thank you booth for your effort and help.

Br jorgen

Hi Guys.
I have got a BH1750 on order, so I will see if I can resolve any hardware issues.