This is smart. You can always respin later when you run into other problems. I have been trying to switch my thinking to “buy then build” for this reason. If you have a proof of concept working, you’ll have a much better idea if/when you need to build int the future.
Choices, choices, choices. Changing horses midstream is almost always a mistake… Getting one thing working properly and progressing from there incrementally is always better… Except I have a very nice atmega128-16AU based development board that just - works. It was not cheap and is loaded with more peripherals that you could shake a stick at…
Ok back to waiting for the new PCBs, and using atmel studio 6.2 to cobble together modbusRTU master routines.
Power board is probably going to be home grown based on the BQ24091DGQT. A nice simple circuit and makes me feel happier than using a 2 USD Chinese board feeding a large lipo (ie a small bomb). Maybe cheaping out on this area would be a mistake.
Yeah, LiIon stuff should be taken with care. Buying parts with built in temp monitors and low voltage protections is usually worth the extra money, at least in low volume projects. And that’s before even looking at the charging circuit. We’re benefiting from this technology being everywhere, the parts have dropped in price dramatically.
After everything I said I pulled a lipo charging board from my parts bin and a spare, new lipo battery and did the deed. Everything runs cool and at the moment I am getting 80% capacity. Maybe this is the fact the battery has a protection circuit on board as well as the charger. Or maybe the programmable load need to be set at a lower discharge current to squeeze out the remaining juice better, time to play.
I have changed the programming resister to 1/3C charge and will take out the fixed value ‘thermister’ and put in a real one bonded to the battery. The datasheets clearly say a fixed resister is ok but thermal protection is just common sense. This is also easy to test as well to increase the ‘comfort factor’.
Next a few cycles using the wireless charger to see how long a full charge will take but no surprises are expected. I still have to wait for the better sized batteries to arrive and the charge chip that can go on an OSH-Park $5 board as it is so small.
Whichever board gets used there will be a usb socket which will be accessible from underneath the train. That will get things started whilst I try and ‘blend’ in a charge coil into the landscape.
Modbus. I have just noticed that my programmable load is modbus enabled so I have a known good PLC to point to. It provides very detailed information of what is available over modbus, how to calculate the CRC, a ‘Complete Command Frame Analysis’, etc. This is going to be very useful indeed.
Luckily the 'MODBUS APPLICATION PROTOCOL SPECIFICATION ’ is nicely written with loads of clear examples. Reverse engineering someone else’s modbus arduino code is just getting messy. I am not sure what it is written in anyway. So it is back to basics and implementing everything in the RFC, in the most simple and generic way possible. This is where modbus being at level 7 of the OSI model makes life so much easier. Just another application…
Is that MODBUS spec somewhere public?
A code skeleton written for a modbus PLC and an atmega128 is in place. So the ideas are there but the new PCBs are on their way and the components so a PLC is going to be built and mounted in an enclosure before the 128 code is converted in sections into that for the 328. I will use a modified 9 pin D female connector on the enclosure which will not accept an rs232 cable.
My programmable load uses modbus via a 9 pin D connector, rs232 but TTL level. They warn against connecting a real rs232 cable as it would damage the interface. My experience and knowledge is rudimentary but I really think that is crap. Make connectors physically unique as if there is a way to blow something up people will find it and it will not be there fault.
Yeah, I’d be surprised if the cable would damage anything. Perhaps they’re assuming by putting a blanket ban on those cables, it’ll also prevent people from plugging in something that has a higher voltage (actual RS232) on the other end?
Completely unexciting battery management board. I only decided to produce one as the pcb costs are just over 1 USD each. Total cost with chip is about 3 USD per board . The advantage of this implementation is I am using a thermister which will be thermal paste stuck onto the lipo.
Input will be from the inductive charger which works fine. I might add a surface mount micro usb socket though that is probably best left to v2 of the board. It could also be mounted on the back which will another KiCad exercise.
Technically there is no such thing, it’s either RS232 or it’s not. The RS232 standard defines the physical interface including voltage levels. A mark (1) is transmitted as -5V to -15V while a space (0) is transmitted as +5V to +15V. Not very compatible with TTL or CMOS. These days serial ports are derived directly from pins on the SoC which is likely running at 3.3V and therefore may not be too happy with +/-15V signals on it’s pins. You may be using the same connector, maybe even the same pinout, but it’s not RS232. Technically it’s not even TTL.
Of course using a “real” RS232 cable is not going to cause any problems unless the other end is connected to a “real” RS232 port. Another thing to keep in mind with regards to a “real” RS232 cable is that sometimes they have the loopback handshaking signals, which simply shorts some of the pins together, while others are “null modem” cables meaning some wires are crossed from one end to the other. So if you use other pins on the DE-9 for other signals you might want to check your RS232 cable.
My point here is they have a D type 9 pin connector on the rear of the instrument which it would be really easy for someone to assume is RS232. Above and below this load is a PSU and DMM both of which have real RS232 interfaces on them. The instrument is supplied with comm software but no adapters. It would be very easy to make a mistake and plug in an RS232 cable from a PC.
The manual (not provided but downloadable from their website) details the precautions necessary and the part number for the special adapter sold separately. My criticism is they should have used a modified socket unable to take a normal 9 pin D type plug to prevent mistakes being made.
In my case I am using the 9pin D type as it is robust, and cheap. I am making my own cables which will be modified to fit my modified sockets. Standard RS232 will not fit, the documentation will provide details but it will not be possible to break anything anyway.
Which is pin 1?
I suspect bottom left but there is no dimple, dot or cutout. I guess the line gives it away but before I go any further being certain would be good. Thanks.
Yep. The beveled side is the other indicator.
WOW. Dead shorts from power to ground can be pigs to find. The solder mask registration was a gnats kneecap out so the solder from an 0805 resistor just bridged a nearby track that was only 90% masked. I had to crank up the microscope to full blast and look at every component in turn and it was still very difficult to spot. Just imagine if this had been a large board.
Check out the post PCB Manufacture Troubleshooting from @hedrickbt . I have had this issue too but it was on more than just one reistor.
Brilliant link. Thanks.
This is why I hate software so much. Well a few reasons. On the atmega128 dev board the RX interrupts worked fine. I could send data in and out. On the atmega328 boards (ie mine) the ISR for receipt is triggered but the data which kicked off the interrupt is blank. I cannot afford the tools that can step into an ISR and I am not too sure how to trigger a data receipt interrupt with the simulator. Or if it would be meaningful. The Data Visualiser works for monitoring data out but I cannot send it in and have the code stop on a breakpoint.
So in deep frustration I looked at the STM32 ARM cortex M4 MCU. (particularly the very nice, quick, dev board (STMicroelectronics NUCLEO-F401RE ) which is super cheap and loads of good tools. A bit more rummaging and there is a MBED 5 port of the freeModbus library. Nirvana!!
Click on API documentation. Like almost all software developers I have ever known documentation is (unless I am being really myopic) totally missing. Just the source code. How many developers have said “My code is self commentating, I need almost no comments or documentation”. OK I am ranting but I am a massive believer in documenting everything. I would rather plow 50 pages of dense but totally comprehensive explanatory text than any number of comments that only the author understood.
New boards (the final ones from a cheaper supplier) are on the way. If they are good I will get the motivation to try again or not use interrupts for data receipt which is possible but painful. I have a bread-boarded atmega328P so I could dig out the logic analyzer and have a trace on every pin. Old fashioned perhaps but why not if it helps?
The power board PCB is due soon and all the parts are in including a nice compact lipo so at least that should be finished in the next couple of days.
Yeah, this had me excited until I read the rest. No one else is utilizing this/helping document it on the web? Any chance to ask about it on their forums as well? Maybe there’s a hidden PDF somewhere?
I always think this is a good idea regardless, just to check that reality is matching what I’m seeing on screen. In my case it’s almost always overkill…but at least i know it is 