The 2021 Winnebago Revel comes with a new Lithium Ion battery pack and Xantrex related charging hardware. There seems to be some warts in the design that cause issues. Most of them relate to temperature and charging - Li battery chemistry is sensitive to charging at low temps so Winnebago attempted to protect against this. As has been discovered by the user community, the fact that Revel alternator is INTERNALLY controlled forces the system to jump through hoops to not damage the batteries. Basically it narrows the acceptable window for charging. An alternate method of EXTERNAL control can be implemented to correct this, but Winnebago chose not to go this way (more $$).

Here was my summary of the temperature issue :

• The Battery BMS won’t allow charging below 35F (Li chemistry doesn’t like)
• The Battery heater jacket supplied by WBO is designed to keep the batteries around 45F
• The Senasys Thermo Switch closes at 50F

The thermo switch is important as the ACR will let the alternator field energize, but the BMS might be shut down, causing an over-voltage condition and potential component damage. So the thermo switch effectively isolates the alternator until it’s sure the batteries will be available to sink the charge. (or something like that). 

So in effect the batteries won’t charge from the alternator until the thermo switch sees 50F and since it’s attached to the metal structure of the van, it’s challenged to reach this temp on cold days. 
There are other potential failure modes related to the ACR: 

• WBO wiring errors
• Faulty unit - needs to be upgraded

And ideally the Lithionics battery BMS should directly control the alternator output in a closed loop control design. 

An additional point of confusion relates to the way the battery reports how charged it is. It's not a Winnebago or Xantrex issue really, it's about the way the state of charge is calculated. The built in battery management system watches charge going in and out and keeps track. Unfortunately it's not a terrible accurate way of doing things and you need to reset the counter by fully charging the battery. This can only be accomplished (in the Revel) with plugging in to shore power and letting it charge until the batteries won't take any more current. Neither the secondary alternator nor the solar panels can get you to 100%. So many folks think they have a  full charge, but you don't because of SOC drift.

All this got me to wonder what's REALLY going on. I realized that since the BMS in the batteries have a Bluetooth LE server, I could write a little Arduino program to get at it. Well as long as you're collecting data from the house batteries, why not also get the chassis battery? And since this whole thing seems to be temperature related, why not capture a few temps? 

So in the end I ended up with a little system that I've named "VanNerd" that consists of:

• Arduino Nano 33 IoT for Bluetooth LE and WiFi capability
• eInk display to see what going on
• 5 Dallas One Wire DS18B20 Digital temp sensors (Inside, Outside, Water Pump, Macerator, Reefer)
• (These are the ones I used on Amazon - Waterproof Temp Sensors )
• Voltage divider for the Chassis battery
• Quickturn PCB to assemble the thing on
• Google Firebase account
• iPhone app

In order to capture and store the data, I implemented a Google Firebase backend, so the Arduino will take readings every 5 mins, then upload to Google every hour or so. You might ask, "Upload to Google, How?" Well I took two approaches - WiFI in the van and WiFi at my house. (I have the van hotspot set up, so when you're driving the Arduino could connect.) Basically the Arduino tries to connect with one, then the other. If both fail, it just tries in another hour. In the interim, it stores the data on a SD card. 

Of course you can't stop here - in order to SEE the data you need a way to get it out of Firebase, so I had to write a little iPhone app to visualize the data. I had always wanted to try to write an app, so I learned enough about Flutter to do so. 

Here's the prototype. At this point, all 5 temp sensors where mounted on the breadboard and I hadn't hooked up the chassis battery. I taped it down in the galley so I could drive around with it running.

Installation Notes:

The following are some pictures from the install. I've used the DS18B20 in other projects and really like it's digital and you can string a bunch of them together to quickly build a network. I found a version of them in a waterproof construction - which looked perfect. 

1. Water Pump - I just zip tied it to the top. I thought about placing it on the tank output - which is close. 
2. Macerator - Again I just zip tied it to the top fitting
3. Fridge - After extracting the fridge - I found there was a plastic cover over a hole used to run the refrigeration and power. I just force the sensor through and managed to tuck it behind the plastic cover on the inside. You can't really see it.
4. Outside - I just placed the sensor in the gap between the galley and sliding door. It's probably not the best placement, but it's protected and I can move it pretty easily if it turns out it's a bad idea.
5. Inside - originally I was going to mount one somewhere - but realized I could just solder it onto my pcb directly. Again - I may need to move this if it turns out the temp is too influenced by the Arduino. 

I used an Arduino Nano 33 IoT as it can do Bluetooth LE and WiFi (although not at the same time). It took a long while to get this to talk to the batteries reliably. I found a cool eInk display at Adafruit that also incorporated an SD card. I was hoping to make this fairly low power. 

I got my pcbs manufactured by OSHPark. I've used them before and it's works great. They will take native EagleCAD files so you don't have to mess with gerbers. For 3 boards it was about $30 and took around 2.5 weeks. I only found 2 layout errors on the finished boards - which were recoverable. 

I realized the OnePlace already had connections to the house and chassis battery. I wanted to power the project from the house batteries, but wanted to monitor the chassis battery. So I fashioned an adapter pigtail to tap into these. It's a standard Molex 8 position connector. 

One design idea I incorporated was to only sample the chassis battery for a few milliseconds so that I wouldn't inadvertently drain it by leaving it hooked up to the voltage divider (always a small amount of drain). The project being hooked to the house batteries is supplied by a huge battery and it's recharged via solar - so shouldn't be a problem.

Since there was an SD card, I set up a small preferences file so I can change a few parameters by changing the file - things like upload frequency, sample frequency, WiFi password, etc.

I used Google's Firebase backend for 4 main reasons.

• I was interested in how it worked.
• Developer access is free up to a certain use level so you can write/develop your app with no downside
• My friend was working on his project and helped me
• I could use Google's Flutter framework for the app development

At the moment, with 5 minute samples being uploaded every hour is running me about $1.25/day. I might be able to lower that as I'm not exactly sure which piece of the backend incurs the most costs. 

Here's the final product. eInk screen, Arduino on the pcb. It's just double stick taped up above the one place. Right now there is no user interface - just a screen. There's no way to get at realtime info - it's delayed by the upload period - currently one hour. 

Here's some of my first data with the van sitting in my driveway. Nothing is going on, but the fridge is turned to 4. (Yes it's hot outside -Northern California). You can see that the fridge is pulling a couple of amps very periodically. When the sun comes up around 7:30, you can see the outside temp increases and the solar panels start charging. They peak at 4 amps. Looks like around 11am the batteries get full. Also the reefer swings between 30 to 40 or so. It was empty, so I imagine this would be stable with a bunch of cold food in it. 

Many years ago I started a project to monitor various systems around my house.  I designed and built a system based on Arduinos, Python and MySQL.  I placed various sensors all around my house, connected them with ethernet, and I can data log various things - like water and energy consumption, room temps, etc. Which brings us to today's fun. 

I live in a rural setting, so I have a well. As you might be aware, living in Northern California has it's ups and downs (like earthquakes, fire, drought, etc), and gives me the opportunity to worry about my very drought and population stressed aquifer. Many of my neighbors have their wells go dry in the last several years due to overpumping and poor water management. In fact my well went dry about 4 years ago and I was forced to drill a new, deeper one. However the old well was left in place. I was hoping it would perk up at some point. 

Roll forward to this year. I finally got around to have a sounding tube installed the old well. (A sounding tube is just a bunch of PVC pipe that runs  in the bore from the surface down to the well pump. My sounding tube turned out to be 546 feet deep. I purchased a water depth sensor from Keller (Keller Acculevel). I've used these before and find them accurate and easy to use. The one I selected, has a RS-485/MODBUS output and needs a 12v source. 

The "problem" with this installation is the well head is down a hill and several hundred yards from my house. My other installs have had ethernet close enough, so I haven't had to deal with this before. I settled on using a wireless link of some type. I played around with some DIY LoRA radios and they just didn't have the range to make it reliably. So I looked for a more robust solution. I found an RS485 Transceiver (EByte E32-DTU) on eBay for around $25. (You need to purchase antennas separately.) I went with the 433MHz option as I figured that would have better range and be a bit less line of sight.  I also found a wall wart that would accept 220v and output 12v. 

Since I've used them before I already had some Arduino code that worked (it's standard MODBUS stuff, so pretty straightforward). 

Here is the sensor with it's cable and the well head. The 1" cap for the sounding tube has been removed from the well head. I just lowered the sensor down the hole, then put the tail of the cable through conduit to my weatherproof box. 
​

And here's the conduit buttoned up.

The sensor box consists of a 12v supply, the RS485 transceiver, and a tubed filled with desiccant to terminate the atmospheric balance tube. (You can't get any moisture down this tube or you'll get bad depth readings. ) I was lucky that the well electrical box had a 1 1/2" pipe fitting on the top I could mount my weatherproof box too. 

Here's one of my Arduino based nodes. This communicates with the well via the transceiver, decodes the MODBUS stream, converts it to my internal protocol and sends it out ethernet to my database. As you can see, this well is no longer dry, so I can plan to start using it!

(My well pump is sitting 546 below the surface, this is where the sensor sits. The water depth is showing as 246 feet, so the top of the water is around 300 feet below the surface.)

Here's the basic layout of the shop.  The circle with an "x" in it represents a ball valve.
​
Below is a pic of the chart in ThingSpeak. The slopes of the different curve segments are calculated below:

So it appears the best the system can do is around 2 psi/hr. That's with as little of the system as possible in the mix, i.e. best case. That said ,there's still the compressor check valve, a water separator/filter, air line quick disconnect fitting, and 3 ball valves in the mix. It's possible the air line quick disconnect fitting could be the bulk of it, however the filter also has an auto drain feature which could be leaking too.

UPDATE: I've been opening up each end point separately and it looks like the Bridgeport is kinda a problem. I'm pretty sure it's the Kurt Power Drawbar IN/OUT switch - I knew it was leaking, but it's leaking more than I wanted. I think the rest of leaks are probably a collection of minor things I'll have to find by soapy water, etc. 

A couple of years of ago I finally added hard lines to my air compressor throughout the shop. What a nice upgrade! No more hoses all over the floor. However, it seems my copper sweating skills are maybe not what they should be as it seems to leak a fair amount of air. After I switch off the compressor it takes something like 4 hours for the system to depressurize. 

I felt I could do better. 

But how to isolate the problem? And how to make it a complex project? 

Well, that's easy. Just build a wireless network connected microcontroller with a pressure sensor, an SD card for logging, and a graphical display. Have all your data get collected in two ways - 1) local to the SD Card and 2) upload to ThingSpeak.com. 

My thinking is to attach the logger to different segments of the air line. As I move away from the compressor -  therefore adding more pipe joints, valves, equipment - I should be able to deduce from the pressure decay rates what the relative leak rates are per section. That should give me an idea of what to work on. Additionally, I can verify my repairs in quantitative terms. 

So after a few days of cobbling things together

Here you can see it's attached to my air lines - running about 115psi.

Close up of the mess. The screen is an older Arduino TFT (now discontinued) with an SD card socket. The smaller chip above that is an ESP8266 WiFi chip. For $5 you can't beat it!  

The ESP8266 is a 3.3v part which needs some juice when transmitting. I happen to have had lying around an old  XBee shield that I had previously added a 2 channel level shifter to. It took care of both issues as it also has a robust 3.3v power supply. 

Here's a link to the ThingSpeak page where I'm uploading the data :  https://thingspeak.com/channels/6008

I'll have to update this as start logging the system and try to figure it out.