With the replacement of my Power Boost 1000C – based charger module with the TP5100, I needed to change the charging station supply voltage from +5V to +12V. Unfortunately, the modulated IR beam signal is generated by a Teensy 3.2 module, which requires +5V (it’s actually a 3.3V module, but can accept power of up to +5V), so now I needed both +5 and +12V on the charging station. The answer was to add a simple 3-pin regulator, as shown in the schematic below
Updated charging station schematic showing addition of a 3-pin 12-to-5V regulator
The original Teensy 3.2 side
The original 5V charging station layout, rear view
I think it is important that Wall-E2 have an accurate measurement of battery voltage, so that he knows when he should be looking for his next charging fix, and more importantly, so he can stop and yell for help if the battery voltage gets dangerously low. In addition, I would like to monitor the battery voltage during charge, so Wall-E2 can report & display charging progress to any interested humans (like me). ;-).
From what I’ve read, it appears a LiPo cell can go down to about 3V without damage, or 6V for my 2-cell stack. So, my operating voltage range is from full charge (approx 8.4V) to empty (6.0V). My first cut at battery voltage monitoring was a simple 1/3 – 2/3 resistive voltage divider tied to an analog input; simply measure the voltage, multiply by 3, and voila – battery voltage!
Only it didn’t work that way; once the battery voltage dropped below about 7V, the drop across the Arduino Mega’s voltage regulator wasn’t sufficient to maintain regulated 5V, so the Mega’s bus voltage began to drop. At Vbatt = 6V, the Mega was still running OK, but the bus voltage was down to 4V, and the A/D reference was no longer what it should be – rats!
In addition, once I started looking at this issue, I realized I was throwing away most of the A/D dynamic range with the divider idea. with a 5V A/D reference and a 1/3 divider, the A/D input voltage only varies between 2.0 and 2.8V for an input range between 6 and 8.4V. In other words, I’m only using 0.8V of the available 5V range or about 16%.
So, I thought that maybe I should implement a level shifter, so the sensed voltage varies from 0 to 2.4 as the battery voltage varies from 6 to 8.4 – and then use the Mega’s internal 2.56V reference for the A/D operation. This would mean an immediate increase in dynamic range usage from 16% to almost 94%, and would increase resolution from about 15mV/count to about 2.5mv/count. To do the level shifting, I’ll need a 6V zener, such as the 1N5233B, available from Mouser for a few pennies each.
One last voltage issue to be addressed is the problem with the Mega’s onboard regulator dropping out for battery voltages between 7 and 6V – this is almost half of the available voltage range. Eventually I decided to address this problem by replacing (or rather, bypassing) the onboard regulator with a low dropout (LDO) regulator such as the LF50CV-DG , available from Mouser for less than $1 each. The LF50CV-DG can maintain 5V output down to well below my 6V battery voltage cutoff limit, so it is a good match.
23 March 2018 Update:
I just received the LF50CV-DG regulator and 1N5233B parts from Mouser, so I’m in the process of installing them onto Wall-E2. The regulator will take the place of the MOSFET low-drop diode I installed on the Pololu Wixel Shield some time ago as part of my old PB1000C-based charging subsystem, and is now no longer needed. The following photos show the installation:
Wixel shield showing MOSFET diode to be replaced by LDO 5V regulator
LF50CV-DG LDO 5V regulator and 1N5233B 6V Zener diode installed on Wixel shield
Rear of Wixel shield showing regulator output connection to +5V bus
25 March Update:
While testing the above arrangement, I managed to somehow kill my Mega 2560 SBC (I think my old power supply did it in, but I’m not sure). So, in the process of recovering from this mess, I also decided to replace my old Wixel shield for the latest version (v1.1) with updated level-shifting circuits and carry-throughs for the added pins on the UNO R3, Mega, and cousins. The new layout is shown below
Updated Wixel shield board with LDO 5V regulator and level-shifter circuit installed
Once I got everything back together, I started over with testing the LDO 5V regulator and level shifter performance, and ran into another problem. The original idea was to use the 1N5233B 6V zener to level shift 6-8.4V to 0-2.4V so the range would fit into the range obtainable using the Mega’s internal 2.56V ADC reference. This worked almost perfectly, but the combination of a slightly lower Vz (5.84 vs 6.00V) and a slightly lower Vref (2.42 vs 2.56V) caused the ADC to hit full scale (1023 counts) at about 8.26V (2.44Vref + 5.84Vz = 8.26V). Most unfortunate, as I really needed to accurately measure Vbatt to at least 8.4V, nominal end-of-charge voltage for a 2-cell LiPo stack.
So, I needed to expand the measurable voltage range at least a little bit on the top end. With the installation of the LF50CV LDO 5V regulator, I could now do that by reverting to the internal 5V reference, as the LDO easily maintains 5V output all the way down to 6V, the cutoff voltage for my battery stack. But, this wastes half the available ADC range, as the ADC input voltage for Vbatt = 8.4 is only 8.4-5.84 = 2.56V. So, after some more Googling through Arduino-space, I realized I could tie the Mega’s AREF pin to the Mega’s 3.3V output line and use ‘analogReference(EXTERNAL)’ to obtain an ADC range from 0-3.3V, corresponding to a Vbatt range of 0 to (5.84+3.3)= 9.14V – perfect!
After making this change I ran some measurements to verify the input range and accuracy, as displayed in the following Excel plot
Measured vs Calculated Vbatt, with raw ADC values
As can be seen in the above plot, the measured and calculated voltage plots are almost perfectly overlaid, and well within the accuracy requirements for effective battery management.
Summary:
As usual, what started out as a simple plan (in this case, to accurately measure the battery voltage) rapidly metastasized into a full-blown hardware and software project, complete with howls of anguish and gnashing of teeth. The first idea was to use a simple 1/3 resistive voltage divider input to a ADC port referenced to 5V. This worked OK, but failed at battery voltages below 7V because the Mega’s onboard voltage regulator requires an approximately 2V input-output offset. Since I needed to measure Vbatt down to 6V, this was never going to work. In addition, the available measurement accuracy sucked because the 2.5V range of interest was being compressed into 2.5/3 = 0.833V, and with a 5V reference I was using less than 20% of the available ADC counts. The next idea was to replace the onboard regulator with the LF50CV LDO regulator, and use a 6V zener to level shift the range of interest to under 2.56V so that the Mega’s internal 2.56V reference could be used. This almost worked, but I ran out of ADC counts before I ran out of battery voltage – oops. The third (and last, I hope) idea was to change the ADC reference from internal 2.56V to external 3.3V using the AREF pin tied to the Mega’s 3.3V regulated output. This allowed the top voltage to go to a little over 9V, just about perfect for this application.
To paraphrase the saying, “to a man with a hammer, every problem looks like a nail”, “to a man with a 3D printer, every problem looks like a 3D printing opportunity”. And that’s pretty much what happened when I ran across the problem of adapting some 80mm wheels to my Wall E-2 robot, which came originally with 65mm versions. The extra 15mm diameter/7.5mm radius doesn’t sound like much, but it makes a huge difference when navigating over carpet or other small obstacles (like my wife’s slippers).
After a lot of work, I finally was able to print four reasonable quality adaptors, and thought I was home free. Unfortunately, I soon learned that despite my best efforts, the printed adaptors were no match for physics; the wheel eventually worked its way off the motor shaft, just as before – it just took a little longer ;-).
After the usual number of curses, imprecations, and woe-is-me’s, I finally decided to use whatever was left of my engineering brain to actually look at the physics of the situation. When I did so, I realized that my adaptor idea was never going to work. While the adaptor did indeed (after the aforementioned ‘lot of work’) provide for a better fit between the 80mm wheel receptacle and the motor shaft, it also moved the wheel another 9mm or so away from the robot chassis, which put the wheel center of pressure (CP) well outside the adaptor-to-motor shaft parting plane. This meant that the wheel would always be trying to pry the the adaptor off the shaft, and it didn’t take all that long for it to succeed :-(. The following photo illustrates the problem
80mm wheel with 3D-printed adaptor on the left, same wheel directly attached to motor shaft on the right
So, contemplating this problem while drifting off to sleep I was struck by a solution; I could use a small roll pin inserted through the wheel and motor shafts to literally pin them together. The geometrical physics would still cause the wheel to flex the shaft, but the forces wouldn’t be able to overcome the strength of the metal roll pin. Because I knew I would forget this insight if I left it until morning, I staggered out of bed and jumped onto the McMaster-Carr site (they have everything!) to look for an appropriately sized roll pin. I found a 1 x 6mm roll pin that would be perfect for the job, and if I ordered them now they would probably already be on my doorstep when I woke up in the morning.
McMaster-Carr metric roll pins
However, while I was doing the necessary measurements on the motor shaft, I noticed the motor shaft had a axial hole in it, and so did the wheel; hmm, maybe I could simply run the roll pin through the axial hole, instead of cross-wise? Then I thought – wait that hole looks to be slightly smaller than 3mm – maybe I could simply drill/tap it for 3mm and use a 3mm screw (of which I had plenty in different lengths) instead of a roll pin?
So, in just a few minutes I had drilled & tapped the axial hole in the motor shaft of one of my spare motors, drilled out the wheel hole for 3mm clearance, and firmly screwed the wheel to the shaft (the right-hand wheel in the first photo above) – cool!
Now all I have to do is modify all four wheel shafts for 3mm clearance, and all four motor shafts to accept a 3mm screw – piece of cake!
As can be seen in the above photos, the 80mm wheels are now much closer to the chassis. The wheel guards are now much too wide, but I may keep them that way for the moment, as I have already adjusted the charging station lead-in rails to accommodate the (now unnecessary) greater wheelbase – oh well 😉
So, the moral of this little story is: Just because you have a 3-D printer doesn’t mean the solution to every problem is a new 3-D printed piece; and maybe to keep one’s eyes/brain open for even better solutions as they might come along when least expected!
In a recent post, I described my study of the widely available and dirt-cheap TP5100 1/2-cell LiPo battery charger as a possible replacement for my current Adafruit PB1000C-based battery charger. Based on the results of this study, it was clear the TP5100-based system was superior in all respects to my home-brew system:
Twice the charge current (2A vs 1A) means significantly shortened charge times
Much smaller and simpler
Charger current path independent of load path – much lower IR drop
Battery always connected to the system, so no requirement for ultra-low-drop MOSFET diode
Much simpler software – no requirement to monitor status of two separate chargers
No electromechanical relay to screw up.
I constructed a small charger module using some perfboard and a couple of 2-place screw terminals, as shown below (with the previous module shown for size comparison).
New TP5100-based charger module, with previous Adafruit PB1000C-based module below for size comparison. The orange box contains 4 Panasonic 18650 cells. Note the separate charge & load circuits
The following figures show the old and new schematics:
Old battery pack schematic
New battery pack schematic
Now that the load current doesn’t have to go through the charging module, I was able to replace all main battery wiring with #20 wire for lower IR drops, as shown below
Power wiring replaced with #20 wiring, and 2-pin Deans connectors
#20 wiring to main battery buss. Note in-line safety disconnect
The change to the new battery pack also considerably simplified the system hardware and software. The changes to the system schematic are shown below:
Old system schematic. Note the ultra-low-drop MOSFET diode required to keep Arduino Mega alive during charge. and the number of pins required for charge monitoring.
New system schematic. No requirement for diode, as full battery voltage is available at all times. Also, only two pins are required for charge monitoring
The operating system software has also been simplified. Now, instead of monitoring both cell voltages and four different status lines, only two lines have to be monitored. Also, there is now no requirement to correctly sequence the ‘Charger Connect’ and ‘Coil Enable signals in order to accomplish correct charging station connect-disconnect behavior. Now the system simply shuts off the motors when the robot connects to the station, and turns them back on again to disconnect. As an added benefit, the six charge status LEDs have been repurposed to show a crude approximation (based on battery voltage only for the moment) of charge status.
All these changes have caused one minor hiccup in the implementation of the charging station; the new charging voltage is +12V vs +5V as before. As you may recall, the charging station implements a square-wave modulated IR signal, and this signal is produced by a Teensy 3.2 and some associated circuitry, all of which expect +5V. This will require either a dual-output supply, or the addition of an on-board 12-to-5V regulator. This is still up in the air, but I suspect it will land on a simple 3-pin regulator.
So far, all the hardware changes (except for the charging station changes) have been accomplished, but the software changes have yet to be implemented and tested. Stay tuned!
Some time ago I created Bridge Game Reporter (BGR), a wrapper for Ray Spalding’s wonderful Bridge Composer (BC) program, for the Columbus Bridge Center, our local bridge club. Bridge Composer produces really nifty HTML and PDF reports of duplicate bridge games, but using it can become tedious, and non-technically-oriented bridge directors are prone to making mistakes when FTP’ing result files to a website. So, my BGR program automates all that stuff and makes calls into the BC API to make the magic happen. After the inevitable problems and issues, it seemed to be working fine at the CBC, and then Siraj Haji, owner/operator of the Aloha Bridge Club asked me if I would mind sharing the program with him. Siraj had a slightly different setup, and rather than FTP’ing result files to a website, he wanted to email them to just those players who actually played in a particular game, so he and I worked out the strategy for using ACBL player numbers from session reports as a search key into a CSV-formatted email list. After the usual number of mistakes, we got it working. A few days later Siraj mentioned that he also uses Bridge Composer to generate game files for upcoming games, but it was somewhat tedious – could I maybe use my new-found BC superpowers to do something about that? Well, it turns out that the BC guy (Ray Spalding) created a pretty nice API to BC, and provided a WScript/JScript example that did most of what we wanted. After a few days of fumbling around, I figured out most of what was going on behind the curtains, and realized that I could fairly easily add a ‘game generation tool’ to my BGR app to add bulk game generation capabilities. Again after the normal number of mistakes, Siraj reported that this feature seemed to be working – yay!
At some point in this process, after the email feature was added and before the bulk game generation feature, I got another request for the program from another club in the area, so I realized I was going to have to provide an actual installation program and some user documentation. Since I already had this blog site, I decided to use it as the documentation vehicle.
Bridge Game Reporter Features:
Uses Ray Spalding’s Bridge Composer program, which must be installed and active for the magic to work.
Automates the process of calling Bridge Composer with the correct set of files for a particular game.
Optionally automates the process of FTPing Bridge Composer game summary and hand records to a selected website
Optionally automates the process of emailing results to a user-supplied list of email recipients
Automates the process of generating multiple games over a range of dates/times using the ‘Game Generation’ tool.
Main Page:
The main page of the Bridge Game Reporter program is shown below, along with a description of each control area.
Bridge Game Reporter main page
Game Date: The user selects the desired game date from a drop-down calendar display. This date is used to construct the filename to be searched for. The file name format is in the form [yymmdd][session time].ext, where yy = year, mm = month, dd = day, session time = ‘M’ (Morning), ‘A’ (Afternoon), ‘E’ (Evening), or ‘L’ (Late). All input files associated with a particular game will have this format. For instance, for an afternoon game on March 6, 2018, the filename will be 180306A.ext, where ‘ext’ = BRI (or DUP or PBN) for the deal file, BWS for the Bridgemate results file, TXT for the text summary file, HTML for the report output from Bridge Composer, and LOG for the log file optionally created by BGR.
Game Time: The user selects one of ‘Morning’, ‘Afternoon’, ‘Evening’, or ‘Late’. This selection is used to form the ‘MAEL’ suffix to the filename.
Lock Entry Fields: For a particular club setup, most of the fields dealing with file locations can be set once and then never changed again. To prevent inadvertent changes to these fields, this option, when checked, will make them all read-only.
Game Input Folders: The location for the .BRI, .DUP, or .PBN game files, the .TXT summary file, and the .BWS Bridgemate score files. The .BWS file can be skipped, if necessary.
Game Report Folders: The location for the .HTML and the optional .LOG files. This section also contains the ‘FTP to Website’ checkbox and the the URL for the destination website, if this feature is enabled, and the ‘Email to List’ checkbox and corresponding location for the email list document.
Start, Close buttons and logging area: The ‘Start’ button will remain grayed-out until all required input conditions are met, at which time it will become click-able. Clicking ‘Start’ will cause the program to assemble all the required information and send it to Bridge Composer for processing; then it will optionally transmit the results to either a selected website or to addresses on an email list. The ‘Close’ button will close the program. The logging area displays progress and/or error information. If the ‘Save log to folder’ option is checked, then the log file will be saved to [yymmdd][session].LOG in the selected folder.
Set FTP/Email Creds: FTP and/or email server login information (username & password) is saved in the ‘BGR.TXT’ file, which must be in the C:\BGR\ folder (this folder and a default file are automatically created at installation). The format of the BGR.TXT file is
Clicking the Set FTP/Email Creds button will bring up the following dialog box for editing the contents of BGR.TXT. This dialog is password protected, more to prevent inadvertent changes by untrained personnel than for any serious security.
Reset Folders to Defaults: Clicking this button will overwrite the current folder settings with the last-saved set of default settings. This button (and the corresponding ‘Save Current Settings as Defaults’) are almost never used, as the program automatically saves the last set of user settings whenever the program is closed, and automatically restores them the next time the program is launched.
Emailing Results:
The email feature requires four components:
The session summary ([date][session].TXT) file produced by ACBLSCOR containing player names and ACBL player numbers *see 10 July 2021 Update for more info on this
A user-provided file containing email addresses in CSV format (an example is provided)
A user-customized ‘EmailTemplate.txt’ email template file (an example is provided) containing the body of the email to be sent
Any HTML/PDF attachments to be sent. All desired attachments must have the same filename as all the game files for the particular session, with a .HTML or .PDF extension, and must be in the same folder.
The email list must be in CSV format, and must be formatted as follows:
Name,ACBL #,Email Address,Opt out Jody Lastname,R892974,name@ee.net, Marge,L916928,name@hotmail.com, Barb,K778289,name@gmail.com, Daniel Lastname,N184169,name@yahoo.com,yes Luaine,5169593,name@gmail.com,
A ‘yes’ (case-insensitive) in the ‘Opt out’ field will cause that address to be skipped.
The ‘EmailTemplate.TXT’ file format is:
FROM: info@alohabridgeclub.com SUBJECT: Aloha Bridge Club results for [GAMEDATE] – [SESSION] BODY: Aloha,
Thank you for playing. This automated email is intended solely for players in this specific session. Thank you for your support and cooperation.
info@alohabridgeclub.com 614.890.1459
In the above example, the FROM:, SUBJECT:, and BODY: sections are required fields, and must be placed as shown. [GAMEDATE] and [SESSION] are optional fields that will be replaced by the actual game date and the actual session time (‘Morning’, ‘Afternoon’, etc). The resulting email using the above template looks like the following, where ‘[GAMEDATE] – [SESSION]’ was replaced by ‘February 26, 2018 – Evening’
Game Generation Tool:
The game generation tool is intended to automate the process of batch-producing dealer (.PBN or .BRI) files for games over a range of dates and session times. if, for instance, you wished to produce the deal files for all Monday, Wednesday, and Friday afternoon and evening games for the entire month of April you could simply set up the dates and times, and press one button to generate all the game files.
The game generator tool is accessed from the main Bridge Game Reporter page by selecting the ‘Game Generator’ item under the ‘Tools’ menu. The tool dialog is shown below, along with an explanation of each control section.
Start/End Date: The starting and ending dates for game generation (inclusive)
Game Times: Select one or more game time checkboxes to have that session time’s game generated for every applicable date. Checking ‘All’ will enable all times, and unchecking ‘All’ will disable all times.
Game Days: Select one or more game day checkboxes to have games generated for all enabled session times for all those days of the week within the selected date range, inclusive. Checking ‘All’ will enable all days, and unchecking ‘All’ will disable all days.
Selection Summary: This is a read-only running summary of the number of days, times, and total games to be generated. It’s a good idea to check that the ‘Tot Games’ number is what you expect, before starting the generation run.
Destination Folder: The folder to be used as the destination for generated game files. This folder must exist, and must contain the template file ‘handrecord.pbn’ (see below)
Output Format: Bridge Composer can create game files in either .PBN or .BRI format – simply select which one is desired.
Number of boards to generate: Type in the desired number of boards to generate per game. This will typically be 24, 27, or 36, but can be anything. I suggest setting this to 2 or 3 when first getting used to the program.
Generate Games: Starts the generation process. Note that this button won’t be enabled (click-able) until all the prerequisites are met (start/end date, days of week, session times, destination folder, etc). If the button won’t enable, check the log for helpful messages.
handrecord.pbn template file: This is a required file, and it must be present in the folder selected in the ‘Destination Folder’ entry field. This template file is used by Bridge Composer to customize hand record output for your club or organization, as shown below:
2-board game generated using the default ‘handrecord.pbn’ file
The above figure shows a 2-board game generated by Bridge Composer using the default ‘handrecord.pbn’ file. The text in the title area above can be customized for your own club using Bridge Composer’s ‘Format Title Area’ menu as shown below
Once the required customizations have been accomplished, simply save the result back to ‘handrecord.pbn’, and they will show up the next time a game is generated. Note that Bridge Composer supports many other customizations to the ‘handrecord.pbn’ template, but that’s an exercise that is left up to the user ;-).
Installation:
Download and launch BridgeGameReporter.msi to install Bridge Game Reporter on your (Windows only – not MAC) PC. The installation program will do the following:
Install the BGR application in C:\ProgramFiles(x86)\Bridge Game Reporter
Create the folder C:\BGR\ and place a default BGR.TXT file there for ftp/email credentials
Create another BridgeGameReporter folder in your ‘My Documents’ folder to hold the ‘handrecord.pbn’ file required for game generation, and the ‘EmailAddressList_Sample.csv’ and ‘EmailTemplate_Sample.txt’ sample files.
Place a red heart-shaped ‘BGR’ icon on your desktop
Once the installation completes, launch the program using the desktop icon, and fill in fields as required/desired. Note that if you want to use the game generation tool, you should set the Destination Folder field to the ‘BridgeGameReporter’ folder in your ‘My Documents’ folder.
09 July 2021 Update:
When the Aloha Bridge Club restarted face-to-face bridge recently, Siraj Haji ran across a problem when he tried to use BGR to email results to game participants. He got the following error message from the part of the program that uses the Gmail SMTP server:
1
Failed with message:The SMTP server requiresasecure connection orthe client was notauthenticated.The server response was:5.7.0Authentication Required.Learn more at
At first I thought this might be a standard “your username and/or password is incorrect” kind of message, and then later I thought it might be due to Google moving to an SSL based SMTP server during the pandemic. As it turns out, both of these suppositions were wrong. The actual problem was due to Google de-activating the required ‘Less less secure app access‘ setting during the year+ of inactivity on the account. There is actually a note associated with the setting that says “Google will automatically turn this setting OFF if it is not being used”. After turning it back ON again, I was able to successfully send an email using the SMTP server from my debug version of the BGR app (and Siraj confirmed that doing the same thing on his account allowed him to email out the results from his latest game). See the screenshot below:
While I was looking through the BGR code trying to find the problem that was eventually traced down to the above setting, I noticed something that might, or might not, be a bug. The following code:
calls
SearchForMissingFile(TxtFilename,tbSummaryFolder.Text,"TXT") to see if there is a file with the right date and ‘gametime’ configuration, but maybe extra letters. The
SearchForMissingFile(TxtFilename,tbSummaryFolder.Text,"TXT") function is shown below:
//concatenate folder & filename to form final filename
namestr=foldername+"\\"+filestr;
}
else
{
AppendToLog("Eror in GetFullFilename()",Color.Red);
}
returnnamestr;
}
So, if the program can’t find the normal ‘YYMMDD[M/A/E/L].TXT’ file, it looks for ‘YYMMDD[M/A/E/L]P.TXT’ and offers to use it instead. However, it also renames the file (by removing the extra ‘P’), and I don’t know why I decided to do that, rather than, say, copying the file so that both versions would exist. I asked Siraj about this, but it may be that the reason is lost in antiquity.
10 July 2021 Update:
I got the following email back from Siraj when I asked him about the ‘P’ file:
We use the ACBL numbers to find email addresses in a text file. ACBLScore does not include the ACBL number In their Press + Recap report. We run a Short Press report to get the ACBL numbers. That report that’s the ‘P’ in the file name. Recap sheet does not.
So, the mystery is now solved. Siraj generates the ‘P’ file from the regular ACBLScore ‘recap’ file in order to add in ACBL player numbers, to facilitate extraction of email addresses from the overall email address database. Note that the regular ‘recap’ file is still required, as it contains the Board #/Matchpoints grid for each pair number, and is the file that is sent to BridgeComposer to be incorporated into the HTML documentalong with the double-dummy analysis for the game boards.
This then brings up more questions – what happens to the original (non ‘P’) ACBLScore recap output file? Why not just replace the ACBLScore (non ‘P’) file with the ‘P’ version but with the original ACBLScore [GAMEDATE][GAMETIME].TXT filename and avoid the whole problem of not finding the original file, searching for and finding the ‘P’ version, and then offering to then rename it to the original ACBLScore filename?
After another conversation with Siraj, I now understand the following:
The regular ACBLScor summary file ([GAMEDATE][GAMETIME].TXT) file is required for generating the proper HTML file layout from Bridge Composer. The ‘short press’ ([GAMEDATE][GAMETIME]P.TXT) format does not contain all the information needed
The ‘short press’ ([GAMEDATE][GAMETIME]P.TXT) format is also required (for the ’email’ option) because that is the only output that connects ACBL player numbers with player names for the game, and the player numbers are required to extract email addresses from the email list. Using just player names doesn’t work, because they are not necessarily unique, but player numbers are.
The last piece of the puzzle is the mystery of the dialog box that popped up during my initial testing, as shown below:
This dialog led me on a merry chase, as initially I thought (wrongly, as it turned out) that this offer was somehow a good thing and that the extra ‘P’ was just a typo or something. What I didn’t realize at the time was that not having a ‘regular’ summary file was an abortable condition, and that the ‘P’ file wasn’t just due to a typo – the ‘P’ file is also required when the ‘Email to List’ option is selected. In this case, both files are required, and so I should have selected ‘NO’ here (which would have caused the program to abort).
Apparently this feature was incorporated into the program before I added the email-to-list feature for Siraj, to cover cases where the summary file name had somehow gotten corrupted with an extra space or other character, and the situation could be recovered by finding and renaming the errant file name. This works great, right up until the ‘P’ file got added for Siraj’s email feature.
09 June 2022 Update:
Siraj called me with a problem; as it turns out, Google Gmail turned off its ‘use less secure apps’ option as of 31 May 2022, and the Aloha Bridge Club game results email capability went away – oops!
So, I started digging into the problem, and discovered that the workaround was to use their ‘App Password’ option, which turned out to be pretty simple to do. Here’s the link to their help file entry, and I have supplied some screenshots below to show the process, using my Google account – the process should be identical for Siraj’s account.
Open your Gmail client and click on the ‘Google Account’ button, as shown below:
Click on ‘Manage Your Google Account’
Click on the ‘Security’ menu item on the left:
Scroll down to the ‘Signing in to Google’ section as shown below:
Make sure 2-Step Verification is turned ON. If it was OFF, turn it ON and go through the process of establishing 2-step verification.
Click on ‘App Passwords’ as shown below. You may or may not have any app passwords already – I have a couple of data backup applications that use Google Drive, so I already had app passwords for them.
At this point, Google will require you to provide your account credentials again. This is your normal Google login username and password.
This will bring up the ‘App passwords’ screen. Note that my screen shows that I have already created an app password for ‘Bridge Game Reporter’ – your screen may or may not have any entries in the ‘your app passwords’ list. At the bottom are two drop-down lists – ‘Select app’ and ‘Select device’; both will have to be defined. As shown below, the ‘Windows Computer’ selection has been made for the ‘device’:
For ‘Select app’, choose ‘Other (Custom name)‘ as shown:
The ‘Other’ selection brings up a text entry box where you can type in the app name (‘Bridge Game Reporter’) in our case, as shown below. Note that the ‘Generate’ button is now active:
The next screen shows the app password generated by Google for this device and application. Copy/Paste the password from the yellow box to a temporary location. This password will be used, along with your normal user name (‘paynterf@gmail.com’ in my case) in the ’email creds’ dialog box in the Bridge Game Reporter app. Then click on ‘Done’ to exit the box. You will get a ‘Security Alert’ from Google noting that someone has created an app password. You can safely ignore this.
Launch Bridge Game Reporter, and click on the ‘Email Creds’ button at the bottom of the window and enter the access password. The access password is in the BGR.TXT file located in the C:\BGR folder:
This will bring up the email/ftp credentials dialog. In the ‘Email Credentials’ section, make sure the ‘SMTP Host’ is ‘smtp.gmail.com’ as shown, and the ‘Username’ entry is your normal Google username. Then paste the saved application password into the ‘Password’ box, and click on ‘OK’.
At this point, you should be good to go. When Bridge Game Reporter connects to GMail’s SMTP server at ‘smtp.gmail.com’, it will supply the username and password entered above. At least in my case, this worked seamlessly – your mileage may vary!
I have been working on Wall-E2, my autonomous wall-following robot, for almost three years now, and it seems like I have been struggling with the battery and charger arrangement for that entire time. I started out with 4 AA batteries, but quickly moved on to a pair of Sparkfun 2000mAh ‘flat-pack’ cells with Sparkfun chargers, with a relay to switch the batteries from series (RUN) to parallel (CHG) wiring. This worked, but not very well. The flat-pack batteries weren’t a good match for motor control, and I kept burning up charger modules as well. After struggling with this through several iterations, I finally abandoned it entirely in favor of a 7.4V 20C LiPo RC battery and an external charger. This worked much better, but forced me to manually disconnect the battery from the robot and charge it externally – not at all what I wanted. Later on I made another run at the 2-cell series/parallel switching strategy for charging, this time using Adafruit Powerboost 1000C charge modules, each capable of 1A charge rates. Again this worked (actually quite well), but I recently discovered that it has a fatal flaw – this design imposes significant IR drops on the way from the battery terminals to the motors.
Unfortunately, the available technical information on this module is also next to nothing, and what does exist is all in Chinese. Still, this module has the potential for vastly simplifying my charger setup, so I thought it was worth the effort to perform a thorough study.
In a previous post, I described an Arduino controlled charge/discharge test setup for testing operation of my 2-cell parallel/series switched setup, so I decided to modify it for evaluating the TP5100 module, as shown below
View of TP5100 module showing RUN & CHG indicator connections
Charger test setup, in discharge mode (note 1.1A discharge current)
Charger test setup, in charge mode (note 1.8A charge current)
TP5100 Module Test Circuit
Using this setup, I was able to cycle the battery between a 7.5V load and the TP5100 charge module. In order to keep the cycle times down to a dull roar, I set the software to switch to charge when the battery voltage dropped below 7.5V, resulting in the plots shown below.
In this case, the discharge current was about 1.1A, and the observed charge current was about 1.8A. The TP5100 modules seems to work as advertised – with a 12V 5A power supply and a partially charged battery, it successfully charged my 2-cell LiPo pack terminated the charge at about 8.4V (I’m not sure if it is terminating based on current or voltage).
Over the next couple of days, I performed three complete charge/discharge cycles using this same setup. Discharge was terminated at 6V, and charge was terminated when the TP5100 ‘complete’ output changed from open-circuit to active-low. As can be seen in these charts, performance was very consistent – almost 6 hours run time into a 7.5V load, and about 4 hours for a complete recharge.
So here’s what I know now about the TP5100 module
When the ‘1-cell/2-cell’ jumper selector is shorted to select 2-cell, the output voltage stabilized at 8.4 with a 10-15V DC input (I used a 12V 5A supply for the tests). Below about 10V, the output voltage falls below 8.4V
with a partially charged battery stack, output current was about 1.8A at the start, tapering to below 200mA at termination
There is an onboard Red/Blue LED and solder holes for an external bi-color LED. The onboard LED states are:
RED = Charging
Blue = Finished
Both the onboard and external LED connections are tied to +V via the same 1K current limiting resistor. This resistor is routed to the center hole of the 3-hole external LED breakout. The rightmost hole is tied to an open-collector gate that goes LOW upon charge termination, and the leftmost hole is tied to an open-collector gate that goes LOW upon charge initiation. In my testing circuit above, these lines are labelled ‘Fin’ and ‘Chg’ respectively and were routed to digital inputs with 20K pullups on the Arduino UNO.
This is NOT a balance charger – so there may be differences in cell voltages over time. If this is a potential issue, then separate cell protection modules like these should be installed.
Here’s an annotated photo showing the pertinent features:
So, it looks like this TP5100 module will work fine for my 2-cell LiPo application, with the addition of an external 2-cell protection module like the one noted above. Not only will this solve my original IR drop problem, but it is much smaller and simpler too, as shown in the following size comparison shot. Oh well, at least I had a lot of fun building up and testing the original charger module ;-).
In early January of this year I posted about finishing the integration of my new-improved battery charger & battery pack into my new-improved robot chassis. Between then and now I have been working on getting the new robot chassis mated up with the charging station (the new robot chassis is wider, and I also changed to larger diameter wheels) in preparation for renewed field testing.
Unfortunately, just as I was getting ready to move into field testing, my robot started acting funny. About half the time, it wouldn’t disengage from the charging station and instead would reboot. At first I thought the added weight of the new battery pack and robot chassis was causing the motors to stall, so I changed the code to have the robot disconnect at full motor speed rather than 1/2 as before. This made the problem even worse; now not only wouldn’t Wall-E2 disengage from the charger, it wouldn’t even move forward or backward under it’s own power! Clearly something was badly wrong, but I had no clue what it was.
Applying my time-honored troubleshooting – I simply put Wall-E2 aside for a few days and let my subconscious work backwards through all the changes since Wall-E2 had last worked properly. After enough time had elapsed, my subconscious reported back and said:
“You are an idiot. All of the complexity you added in your quest for an on-board charging system has placed that wonderful high-capacity battery pack at the far end of a long series of (relatively) high resistance circuitry, and the IR drop caused by full-speed motor currents is killing you!” “Oh, and by the way, you’re ugly too!”
Well, my subconscious is almost never wrong, and it only took me a little bit of testing to confirm it’s theory. I set the code up to go forward and backward at full speed, and monitored the CPU’s 5V regulated output line with my trusty oscilloscope. As soon as the motor command was executed, the 5V line drooped to less than 3V, and the CPU rebooted – oops!
So now I knew what was happening, and I (or my subconscious anyway) had a good idea why. To confirm the why, I bypassed all the charge-management circuitry and wired my 7.4V 7200mAh battery pack directly into the main robot power line, as shown in the photo below
7.4V 7200mAh battery pack wired directly into robot power
With this setup, the robot not only was able to move forward and backward at full speed, the thing damn near took my arm off when I tried to stop it – whoa!
So, the bottom line is that all the work I put in designing and implementing a really cool on-board dual-cell charge management system had the ultimate effect of making the battery unusable. The operation was a success, but the patient died! ;-).
So, where to go from here? It appears that I have to completely revise my thinking about battery charging and maintenance for Wall-E2. Instead of being in series with the battery, any charging/maintenance system must operate in parallel, and be completely out of the path between the battery pack and the load when the robot is running. Now I realize this is the reason most RC/Hobbyist multi-cell battery packs have a balance charging cable in addition to the main power cable; charging is done completely independently of the output path.
When I first started the charger project, my original goal was to avoid having to remove the battery from the robot to charge it; I wanted Wall-E2 to connect to power and charge itself without human intervention. At the time, I felt the only way to do this was to have the charging circuitry on board, so that only a single DC connection from the charging station was required. I thought the only way to make this happen was to use two of the Adafruit SBC1000 charger modules to charge each of the two cells independently. Unfortunately, the SBC1000’s grounds aren’t isolated, so this meant that I had to disconnect the two battery pack cells from each other to charge them independently and then switch them back together again to run the robot after charging. This worked (rather elegantly if I do say so myself), but had the unintended side-effect of putting too much high-loss circuitry and wiring between the battery pack and the motors.
Now that it is clear that I can’t interfere with the current path to the motors, I know I have to abandon the current charging module design, but what are the alternatives?
The TP5100 is a little module that can balance charge a 2-cell LiPo stack at 2A. It has a dual-color LED output that I might be able to use for charge termination. Unfortunately, the specs are all in Chinese, so it may take some experimentation to figure out.
I can use an external balance charger like the EV Peak e4 ‘cube’ automatic balance charger, and feed the three required wires (ground, B1+, B2+) out through the front of the robot to the charging station. This solves the problem of carrying the charger around, but significantly complicates the interface to the charging station.
Over the last few days I have been struggling with a project to 3D print a small adaptor to allow me to mount some 80mm wheels I bought some time ago to my Wall-E2 autonomous wall-following 4-wheel drive robot.
The original robot came with 56mm wheels and this gave Wall-E2 very little ground clearance. I found some 80mm wheels that I thought would do the trick nicely, but when I tried them, it quickly became apparent that the shaft receptacle on the wheel was significantly larger than the motor shaft, leading to a very bad wobble and catastrophic wheel departures – oops!
Lightweight 4WD Drive Aluminum Mobile Dolly Car Robot Platform for Arduino
original 56mm wheel and companion motor
Ebay ‘Arduino Robot’ motor dimensions
80mm wheel
After some troubleshooting, I discovered that the new 80mm wheels have a shaft receptacle that measures 5.9mm long and 3.6mm wide, while the motor shafts are 5.4mm long and 3.5mm wide. The width is OK, but the longer length is causing the problem.
After thinking (and cursing) a bit, I decided to try printing an adaptor. The larger diameter wheels are also considerably thinner (20mm or so vs 30mm), so there should be room for an adaptor part, as shown below
shaft adaptor for 80mm wheel
And threw it on my PowerSpec 3D PRO (Flashforge Creator Pro knockoff). After just a little fiddling, I got some nice parts, and thought I was done. A couple of days later, I noticed one of the parts was just a little loose on its shaft, so I said to myself – “I’ll just print off another one”. Unfortunately, what came off the printer was really ugly, and completely unusable, even though that same printer had produced nice parts just a few days ago – WTF!? Clearly I had forgotten what magic I had wrought the first time, so now I had to go back and recreate it – bummer. As part of my penance for this crime, I am writing this post so the next time I want to do this, I’ll have the print settings recorded.
Print Settings for ABS
The significant factors in how to get good prints with ABS on this printer appear to be
Print speed
Extrusion factor
The first thing I did was slow the print speed down, but this had only a minor effect on print quality. Going slower helped, but even very slow speeds (like 10mm/sec) didn’t result in clean edges on the male part of the adapter. However, the female portion was very clean, which left me a bit puzzled – why one part but not the other? I finally realized that the difference was that the female piece was perfect because the hole perimeter was the first thing laid down at each slice, then the outside perimeter, and finally the fill material was added last. This meant that the hole perimeter had a chance to cool and solidify before the fill material impinged on its outer surface, and this meant that the perimeter stayed in the same shape as originally laid down. When printing the male part, however, the outer perimeter was laid down first, and then the fill material was immediately added, before the outer perimeter had a chance to cool and solidify, even at the slower speeds. The material making up the fill was pushing the outer perimeter out of shape.
This led me to focus on the extrusion factor. Reducing the extrusion factor from 1.00 to 0.95 had a significant positive impact on the print quality of the male portion of the adaptor. Reducing it again to 0.90 resulted in an even better print, as did a further reduction to 0.85. However, at the 0.85 value, I started to see some degradation in the quality of the female portion, so I backed off to 0.90 as the final value. The following image shows the last seven prints. All were printed at either 20mm/sec or 10mm/sec, and the last three on the right were printed with 10mm/sec and extrusion factors of 0.95, 0.90, and 0.85 respectively.
The last seven prints. the last three on the right were printed at 10mm/sec and with extrusion factors of 0.95, 0.90, and 0.85 respectively
Original and new wheels, with completed adaptor shown
Bottom Line (PowerSpec 3D Pro, Simplify3D):
Material: Gray ABS
Extruder temp: 230 (not critical 220-240 should be OK)
Bed temp: 110 (not critical, 100 should do too)
Speed: 20 or 10mm/sec (maybe faster would be OK, but not much)
So, today I started some field testing, and discovered a major problem – the motors that came with the new chassis don’t have sufficient torque to handle the operating environment – they stall out much too quickly when encountering any movement issues at all. This wasn’t a problem for the previous incarnation of Wall-E2, so clearly the motors that came with the new chassis have different speed/torque specs than before. And, of course, the old motors won’t fit into the new chassis (actually, they do fit, but not with the new battery pack). What a bummer!
So, I started researching dc motors to determine if I could find motors with the speed/torque specs of the old chassis, but with the physical specs of the motors that came with the new one.
Motors in previous ‘Pirate’ chassis:
The specs for the motors that came with the DF Robots ‘Pirate’ chassis are shown below:
Specifications for the motors using in the ‘Pirate’ robot chassis from DFRobots
With a gear ratio of 160, the motors should produce about 160 RPM at At Wall-E2’s normal operating range of 6-7.5V, and can produce a maximum torque of 0.8 kgf-cm (kilogram force – cm).
Motors in new chassis:
A DRIVE MOTOR GEARBOX REDUCTION RATIO: 1:48
DRIVE MOTOR NO-LOAD SPEED: 220RPM
I couldn’t find the max torque specification, but assuming it’s the same basic motor body, the much lower gear ratio should result in the observed higher no-load speed and lower torque.
So, I’m fairly confident that I now know why the motors in the new chassis aren’t performing as well as the old ones – a much lower gear ratio. Now all I need to do is find another motor source with the same form factor as the new ones, but with a gear ratio more like the ones from the older chassis:
Pololu:
I found a 120:1 gear ratio right-angle motor at Pololu
Pololu 120:1 right-angle motor dimensions
Pololu 120:1 right-angle motor
These motors have almost the same exact dimensions as the ones in the new chassis, but they have a shorter (5 vs 9mm) and larger diameter shaft (7 vs 5mm). These are not insurmountable difficulties, but surely I can find a better fit.
Ebay:
So, eventually I ended up back on eBay, the same place where I got the new chassis. But, this time I was a little more informed about what gear ratio I wanted, and so was able to reasonably quickly locate a set of 4 motors (without wheels – I have too many already!), as shown below
4ea 1:120 right-angle shaft motors with 5mm shaft diameter
So, now all I have to do is wait 2-3 weeks for them to arrive, and I should be back in the low(er)-speed, high(er)-torque business!
What a way to start off the new year! The battery charger module for my autonomous wall-following robot Wall-E2 has been completed and tested, and now has been integrated into the robot – yay!!
If you have been following this saga, you will recall that I started working on an internal charging module for Wall-E2 well over a year ago, back in November 2016 with this post. Since then I have gone through several iterations, revisions, and mis-steps (including a semi mind-boggling deep-dive into the details of the Adafruit PowerBoost 1000C specifications in this post). Last month I finally got a complete system (two PowerBoost 1000C’s integrated onto a single PCB with appropriate control and battery switching circuitry) working, and was able to run extensive charge/discharge cycle testing using a simple test circuit and an Arduino Uno to run it. So, now all I had to do was stuff the whole thing back into the robot. This task was made possible by my earlier decision to upgrade Wall-E2’s ride to a slightly larger chassis, so instead of trying to cram 2Kg of battery/charger into a 1Kg space, I now had the pleasure of fitting 2Kg into a 3Kg space – nice! Here are some photos of the integration process.
Battery module shown in the ‘maintenance’ configuration.
Another shot of Battery module in the ‘maintenance’ configuration.
Front cover removed to show how the battery module fits into the robot. Note there is plenty of room for cable runs
Front cover removed to show how the battery module fits into the robot. Note there is plenty of room for cable runs
Rear cover removed to show how the battery module fits into the robot. Note there is plenty of room for cable runs
Rear cover removed to show how the battery module fits into the robot. Note there is plenty of room for cable runs
Now that the battery/charger module has been integrated into the robot chassis, I will have to make some minor changes to the robot operating system to accommodate changes I have made along the way, but these should be easy and straightforward. Then, it will be back to field testing, I hope.