Project Update February 2023

[DeeEmm]

NEW RELEASE: RC4!

Release candidate 4 addresses a number of display issues related to flow and reference depression, specifically that the MAF flow value did not display correctly. I have also added a check to the converted flow value to mask it if the bench is not running.

The next stage of unit testing is to move on to accuracy and repeatability.

If you have comments or feedback related to RC4, please use the official thread at #121

If you wish to raise a bug report please use the bugtracker - https://github.com/DeeEmm/DIY-Flow-Bench/issues

[DeeEmm]

Commit 37f188a contains the following changes

23020701        - Changed conversion from mass flow to volumetric
                - Fixed syntax errors in MAF Data files
                - Renamed main tasks for continuity
                - Added ATM units to pressure conversion 
                - Added conversion between mass flow units
                - Changed MAF datatype to int32
23020201        - Refactored MAF code and Mass to Volumetric conversion
23020102        - Fixed include in MH95_3000_100 MAF Data file
23020101        - Updated ReadMe 
                - Updated DEV_BRANCH in configuration.h
                - Updated MAF Data vectors to long datatype
                - Fixed incorrect build number for RC4 (NOTE prev 31012301)

Most notable is the change to the conversion from mass flow to volumetric. This addresses some inconsistencies in the CFM reading that I was seeing on the bench. I've tested this on the bench and the injected values align with calculated values using online conversion pages.

However, I'm going to hold off from up-revving the RC release until I can do a little more work on this. The new version does not adjust for humidity and so I need to get a better understanding of how I can integrate this. At the moment I'm giving myself a crash course in fluid dynamics, well at least as far as the ideal gas law is concerned.

So If you are finding inconsistencies with the CFM reading in the RC5 release, try the build linked to above.

[DeeEmm]

So I've spent a bit of time comparing the Wemos D1, Arducam ESP32 and Arducam LOTAI boards to determine how to best support these board with the shield.

What I've realised is that it is not possible to support all three boards by using pin configuration parameters. The main issue is that there are several hardware pin assignments that are not reconfigurable, for instance the DAC pins 25 & 26. The issue here is that pins 25 & 26 do not share the same physical pin location between board variants. This means that it is essentially impossible to support several pin configurations on the one shield without introducing bridging links or jumpers. The extent of the differences introduces enough complexity to make it unworkable. The sensible solution is therefore to choose one board as the official board and design the shield to suit.

The Arducam boards have the advantage of onboard SD card support as well as having more free I/O available, however both the ESP32S and LOTAI boards are now discontinued. In my tests I had issues with the I2C communications on the Arducam boards. So whilst they may seem like the obvious choice, the Wemos D1 actually comes in a little ahead in the availability and compatibility stakes. The Wemos D1 is also now available as a clone board making it even cheaper to purchase which for many will be a good thing.

The one tradeoff with the Wemos D1 board is that the pins required for SD Card support are normally used for regular I/O, this has forced a bit of a rethink regarding the I/O availability. However with a little brevity and ingenuity I have managed to reduce the required number of pins to something more suitable whilst still managing to support the planned feature set along side SD Card support.

All of this may seem a little irrelevant at this stage, as many of these features are not planned to be released for several versions, however as we are finalising the shield design it is necessary to ensure that everything works correctly and future pin configurations are considered as we may not have the opportunity to fix them later.

I'll do a little more testing and once happy i'll commit my changes

/DM

[black-top]

Just a quick question, why use an additional sd card if all the data is displayed in the browser, why not save the data directly from the browser? The data still needs to be uploaded to the computer from the cards.

[DeeEmm]

I did previously consider this as an option and may still add support for this. SD Card support was one of the orignal goals due to space limitations on the ESP. I was hoping to use the Arducam boards as these have onboard SD Cards but I could not get them to play nice with the I2C.

The original idea for file management was to save a range of measurements as a lift profile in the format of lift versus flow (a small JSON or CSV file). This can then be viewed as a graph in the GUI. Ultimately the goal would be that the GUI can display multiple lift profiles allowing you to easily compare previous results.

By storing the data on the ESP(SD Card) there is essentially no need to use a computer. In most cases the bench can be used with a cheap tablet, negating the need for a laptop.

Files can also easily be downloaded to your computer for more detailed analysis if you wish by clicking on the filename in the file list. This is similar process for downloading the existing config files.

Of course this functionality is way off in the future, but as I am finalising the shield pin definition I needed to include the SD card if it was to be utilised later.

[DeeEmm]

OK. This is what I have come up with for the pin configuration

/***********************************************************
 * OFFICIAL DIYFB Shield With Wemos D1 R32
 *
 ***/
#ifdef WEMOS_D1_R32

    #define BOARD_TYPE              "WEMOS_D1_R32"

    // Define Physical Pins
    
    // VAC CONTROL
    #define VAC_SPEED_PIN               25                      // Built in DAC1 - used for speed reference for VFD (0-3v)
    #define VAC_BLEED_VALVE_PIN         26                      // Built in DAC2 - used for bleed valve control
    
    #define VAC_BANK_1_PIN              13                      // vac motor(s) on/off
    #define VAC_BANK_2_PIN              12                      // Provision for 2 stage Vac motor control
    #define VAC_BANK_3_PIN              14                      // Provision for 3 stage Vac motor control
    
    //STEPPER MOTOR CONTROLLER                   
    #define AVO_STEP_PIN                15                      // NOTE: Pin 15 cannot be used for ADC (Analog in)
    #define AVO_DIR_PIN                 27                      
                  
    #define FLOW_VALVE_STEP_PIN         32
    #define FLOW_VALVE_DIR_PIN          33

    #define VCC_3V3_PIN                 99                      // Not required
    #define VCC_5V_PIN                  35                      // 10k-10k divider across 5v supply
    
    // SENSORS
    #define SPEED_SENSOR_PIN            2                       // turbine / rotor speed for turbo / blower flow bench 

    // ORIFICE DETECTION                                                                                    
    #define ORIFICE_BCD_BIT1_PIN        34                                       
    #define ORIFICE_BCD_BIT2_PIN        36                                           
    #define ORIFICE_BCD_BIT3_PIN        39                         

    // NOTE: these inputs are handled by ADC
    #define MAF_PIN                     99                     // NOTE: I2C ADC is used instead
    #define REF_PRESSURE_PIN            99                     // NOTE: I2C ADC is used instead
    #define DIFF_PRESSURE_PIN           99                     // NOTE: I2C ADC is used instead
    #define PITOT_PIN                   99                     // NOTE: I2C ADC is used instead
    
    // NOTE: These inputs are handled by BME280
    #define TEMPERATURE_PIN             99                     // NOTE: I2C BME280 used
    #define REF_BARO_PIN                99                     // NOTE: I2C BME280 used
    #define HUMIDITY_PIN                99                     // NOTE: I2C BME280 used                     
    
    // COMMS    
    #define SERIAL0_TX_PIN              1                       // API
    #define SERIAL0_RX_PIN              3                       // API
    #define SERIAL2_TX_PIN              16                      // GAUGE PROTOCOL
    #define SERIAL2_RX_PIN              17                      // GAUGE PROTOCOL
    #define SDA_PIN                     21                      // BME280 etc
    #define SCL_PIN                     22                      // BME280 etc

    #define SD_CS                       5
    #define SD_MOSI                     23                 
    #define SD_MISO                     19             
    #define SD_SCK                      18                   


    #define WEMOS_SPARE_PIN_1           4                       // NOTE cannot be used for analog                 


#endif

The hardest part of this process has been trying to ensure that all pin restrictions are taken into account. For example if WiFi is in use ADC2 pins (0,2,4,12,13,14,15,25,26 & 27) cannot be used for analog measurement.

There are also some functions that only operate on dedicated pins. For example DAC, Serial, SD and I2C, which when coupled with General I/O restrictions make it challenging to group pin functions together.

You may note that there is only one spare pin. You may not have noted that I also had to utilise the non-standard three pin header as there were simply not enough available I/O to cater for all functions. I also needed to drop the drive enable signal from the stepper motors instead electing to keep the drives powered all the time. These changes have further cemented the choice of Wemos D2 R2 as the officially supported board.

[DeeEmm]

Build 23021501 - 5fd1b73 adds adjustment for Absolute Humidity when calculating the molecular mass or air. It now compensates the calculated air volume based on the humidity of the air.

The release also rolls up a few other changes as below

23021501        - Outline of VFD control
                - Added adjustment for absolute humidity in flow conversion
                - Finalised pin mapping for Wemos D1
23021301        - Added pin outs for Arducam boards (UNTESTED)
                - Updated README
                - Fixed sensor type display on info page
                - Tidied pinouts from Wemos D1 (For shield compatibility)
23020901        - Display MAC Address
                - Some improvements to WiFi
                - Changed default STA Password
23020801        - Substituted sensors->getMAFvolts for hardware->getADCvolts

The most notable of these is the finalisation of the pin mapping for the shield. There's also some minor improvements to the wifi handling as well.

I'm going to roll this release up and publish it as RC5

[DeeEmm]

Release Candidate 5 now published - https://github.com/DeeEmm/DIY-Flow-Bench/releases/tag/V.2.0-RC.5

[black-top]

I received the XGZP6899A 5V -10-10KPA sensor today. Can you add calibration to the official code? I will try to test with the latest code in the near future.

[DeeEmm]

Sure. I'll take a look at it next week. I also managed to get hold of some of the same sensor but in a -7 to +7 kPa range so I'll add that in too. They probably have very similar transfer functions.

[DeeEmm]

I've added the transfer functions for both sensors. You can download the updated code from the WIP branch

One thing to note is that the datasheet did not contain the transfer function but does state that the output is linear so I calculated the transfer function based on the output range (0.5v - 4.5v).

[black-top]

Thank You. I will test it soon. I see that it needs few additional components, looks like pull down resistor for signal and current limiting resistor with 5v zener over voltage protection for power supply. This sensor may be more sensitive to power supply.

[DeeEmm]

I'm not using a zener. I suspect it might just be a belts-and-braces approach for the XGZP documentation to specify one as they would not assume a suitably regulated supply.

I think that the LM2596 regulators should be good enough as the XGZP's state a max over-voltage of 6.5v (for the 5v devices) and the 5v LM2569's will regulate to 5.25v. However it's not that much of an issue to add Zeners into the revised design with the XGZP pads if they are required. This is something we should try to validate as part of the unit testing.

On that subject I do however note that the fixed voltage versions of the LM596's have a better efficiency than the variable versions (which I have been using). It may pay to select the fixed versions as a result.

[DeeEmm]

I've updated the WIKI to include the finalised pin designations along with the field connections for the official shield.

https://github.com/DeeEmm/DIY-Flow-Bench/wiki/shield-overview

[DeeEmm]

I've almost finalised the updated PCB design. I just need to review PCB track sizes and verify the previously proposed changes.

Once this is finalised I will order some more boards.

[DeeEmm]

OK PCB's ordered. Lets see how many mistakes I've got this time lol.

[DeeEmm]

I've created a dedicated thread for discussions relating to the V2.0 shield.

#129

[DeeEmm]

Build a6fa10d adds support for XGZP6899A007KPDPN and XGZP6899A010KPDPN pressure sensors

[DeeEmm]

Build 6447108 adds support for a swirl encoder. Whilst this was not on the immediate roadmap it was a simple addition. The change however is untested as I do not have a quadrature encoder to test with.

Encoder requires two pin connections as defined in pins.h for channel A and B
The swirl function is enabled / disabled in configuration.h

Swirl is then reported on main page (click on Pitot tile to swap to Swirl)

Swirl is reported as a speed value and will be negative when rotating backwards.

[DeeEmm]

The MAF sensor should not make a difference, they are basically the same code, just with different values.

There are some changes in the WIFI code from earlier versions to address network stability. You may see issues as a result of your router cache but this should clear up when the cache expires. You can see above that one of the connection attempts failed but hen it connected when it retried. Each retry takes some time however and this might be the delay you are seeing.

Keep a watch on it, hopefully it will settle down.

[black-top]

The serial monitor shows that the device is connected to my wifi network, but with the ip from the serial monitor, the diyfb page does not load for me. The only time I can connect to the diyfb page is when I connect directly to the diyfb wifi. And for some reason it always connects to my wifi only the second time.

[black-top]

I rebooted my wifi router. Everything seems to work better. However, it is noticeably slower than with the previous version of the code.

[DeeEmm]

That might be because the refresh rate has been reduced to 500ms. I've been trying to stabilise the communications between the ESP and browser to reduce transmission errors. I'm still not 100% happy with it but it is pretty stable here. So I am definitely interested to see how you find it.

I believe the router issue relates to the mac address stored in the routers cache. For some reason it see's the updated ESP as a new device but as it already has the mac address stored it detects it as a spoofing attempt.

[DeeEmm]

If you want to play around with the refresh rates you can find the following in configuration.h

#define VTASK_DELAY_ADC 500
#define VTASK_DELAY_BME 500
#define VTASK_DELAY_SSE 500

These relate to how frequently the main loop tasks are run

In addition to this there is also the 'Refresh Rate' setting in the GUI, which is also currently set to 500ms

I reduced all of these to the values shown as I suspect that the system is polling much faster than the sensors update.

There's definitely improvements that can be made

[DeeEmm]

The Swirl Encoder is a two channel quadrature encoder. Any voltage compatible (3.3v) encoder should be suitable. It should also be possible to use 5v encoders if the signals are level shifted down to 3.3v.

Micro optical encoders like those used on micro metal motors are a good option and are available in 3.3v. They are supplied with a trigger wheel and should be easy to mount on a shaft with small bearings in a 3D printed mount.

Some examples...

https://core-electronics.com.au/optical-encoder-pair-kit-for-micro-metal-gearmotors-3-3v.html
https://www.pololu.com/product/2591

These are small enough that they can be mounted unobtrusively.

Here's the performance trends swirl meter for comparison

[black-top]

Great! I will try everything as soon as I have some time. I have a 5V encoder, it is important not to forget about the level shift to 3.3V.