Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by Mr.RC-Cam

  1. Congrats, the WiFi modification is complete. Enjoy!
  2. You'll need a 6-inch (15cm) long RG316 coax cable with SMA receptacle connector. For convenience I suggest purchasing a RG316 SMA extension and cutting off the plug end. Like this: Also needed is a SMA equipped 2.4GHz omni dipole antenna with +2dBi to +3dBi gain. Avoid those cheap Chinese antennas, they often have reduced RF performance. By the way, you can use RP-SMA connectors instead of traditional SMA. But never mix RP-SMA with SMA. Disassembly: Remove the left side panel (5 screws) and the bottom panel (6 screws). Pry off the menu knob. Remove the rotary encoder board (4 screws) and transparent LED lens insert (2 screws). Remove the LCD bezel trim screws (4 places). Remove the front bezel trim. There is some hidden sticky tape holding it down, so slowly pry it off to prevent damage. Unplug the two I/O cables. Pull out the LCD board. Note: The existing antenna is a PCB microstrip located on the LCD PC Board. See image below. We need to cut it away and then add the external antenna. PC Board Copper Trace Cuts: Use a sharp knife and scratch off a small rectangular area of solder mask near C17 to expose the copper ground plane. Solder tin the GND area. See photo below. Use a sharp knife and CUT the Antenna's feedline trace from the C7 coupling cap. See photo below. Use a magnifier and visually inspect the CUT. Next use an ohmmeter and confirm it's no longer electrically connected to the nearby pad on C7. Coax Installation: The RG316 coax is prepped (cut signal and shield, pre-tin conductors) and then soldered to the PC board. The center conductor goes to C7 and the shield goes to the GND area created in the previous step. See photo below. Note: The 6-inch length is long enough to reach the left side panel. Avoid longer coax lengths to minimize RF signal attenuation. Thoroughly clean off the flux residue. Add some hot melt glue to strain relieve the coax. Do this away from the RF circuitry; The open area between C15 and R9 is a good place. When you re-install the LCD board just pass the coax (with SMA receptacle connector) through the existing opening that is used for the board's two I/O connectors. No need to cut or drill the LCD's mounting bracket. Antenna / SMA Mounting: Mount the SMA connector on the front-left side of the metal base. You can drill a hole in the metal panel, but I printed a new side panel instead. The location of the SMA connector is shown in the photo below. Validate the mod: Test it out. You should notice that WiFi range is dramatically improved. If not, then you've made a mistake; Check your work again.
  3. Last month (Feb 2019) I purchased a refurbished MP Select Mini V1 3D Printer for $89 USD (with free shipping). The flash price quickly ended, sold out. After the unboxing I found that mine was new (not refurbished). But I had to replace the extruder's cooling fan because it was too noisy. Monoprice did not respond to my email request for a replacement part. Fortunately I had a 12VDC 30mm fan that fit, so problem solved. I quickly discovered that WiFi connections were unreliable. For the record, it works fine when the printer is close to the router in my living room closet. But I need to print elsewhere. And the short range is understandable because the WiFi antenna is inside the printer, surrounded by the heavy sheet metal case. The solution is to convert the printer to use an external antenna. Before I talk about my antenna hack, I would like to point out that there is a fantastic wiki site that discusses a variety of mods for this printer. It includes instructions on how to enable WiFi connectivity, which is a hidden (unadvertised) feature of the V1 printer. I recommend that all MP Select Mini owners bookmark the Wiki: https://www.mpselectmini.com/start With all the formalities out of the way it's time to talk about the Wi-Fi antenna modification. Let's start with some fine print. It's not a hack for the typical mortal. Things to consider: It voids the warranty. Blame only yourself if things don't go as planned. Altering RF circuitry is not like working on a traditional DC circuit. In the RF domain *everything* matters. Good SMD soldering tools and PCB rework experience is a prerequisite. This hack is difficult/risky so proceed with caution. You've been warned. Before you start the modification, first confirm that your printer's WiFi is working. I shouldn't need to say this since the mod is for users that are unhappy with the RF range they are currently getting. But some hackers like to do mods just for the sport of it, so that's the reason for advising to fully test it out before any hacking.
  4. Most of the details to the video signal are lost with a 1MHz scope. But in my experiment, the bottom of V-Sync and peak white amplitude were present, so a crude measurement was possible. Don't purposely purchase a cheap digital scope if you intend to do video measurements. But if you already own it, then try this: First use it to observe a good (calibrated) NTSC or PAL video signal. If the 1Vpp amplitude measurement appears valid then you will have confidence that it can be used to measure/calibrate a bad video signal.
  5. For accurate measurements you need an oscilloscope with an analog bandwidth at least five times the measured signal bandwidth. NTSC and PAL video is about 5MHz, so the scope should be rated for 25MHz or higher bandwidth. I use a TEK2445 analog scope that is 100MHz with TV Sync capabilities. But I've done it with a cheap digital scope that had about 1MHz bandwidth. The results were suitable for crude video signal level calibration. https://www.rc-cam.com/forum/index.php?/topic/2825-using-the-50-digital-scope-to-measure-video-levels/ If your main goal is to calibrate FPV composite video, then there is a low cost ($20 USD) DiY solution that is very accurate. https://www.rc-cam.com/forum/index.php?/topic/4126-diy-fpv-video-calibration-tool-low-cost/
  6. Its bandwidth is too low for accurate measurements.
  7. 900MHz FPV choices are limited. Check the recommendations mentioned here: https://www.rcgroups.com/forums/showthread.php?3109878-what-is-the-current-FPV-VTx-VRx-for-long-range-planes#post39976238
  8. @Terry Thanks for the feedback. It's good to hear from you. @Everyone The Mustang cluster project was presented on the Hackaday site a few days ago. It was nice of them to mention it. https://hackaday.com/2019/02/24/mustang-dash-becomes-bookshelf-art-piece/
  9. This forum area contains the technical details to the CAN2Cluster (2009 Ford Mustang) Instrument Cluster Project. This is also the official area to discuss the project. Do not email or private message the author for technical help! Join the forum and post your technical questions and project comments here. For build photos please review the blog: Click Here! Important fine print: This is NOT a beginner project. The builder should have previous experience with Arduino hardware and its IDE (or an equivalent compiler tool set). Also required is prior experience with electronic construction techniques. The wiring details are limited to what is provided in the schematics. All electronic parts can be found on eBay and Aliexpress. Project Files: Schematic Drawings: https://github.com/thomastech/CAN2Cluster/tree/master/Schematics MP3 Sound Files: https://github.com/thomastech/CAN2Cluster/tree/master/WaveFiles Arduino Software: https://github.com/thomastech/CAN2Cluster/tree/master/Arduino
  10. Here are the demo videos. PART 1: PART 2: Technical Details are posted here: https://goo.gl/xf6mZ3. Epilogue: It seems that the CAN2Cluster project has been a big distraction from the original mission. That is to say, I still haven't replaced the bad dashboard bulb in my car. So pardon me while I grab some tools and get my hands dirty.
  11. It was a productive weekend; The software is done and everything works. Except for that frustrating odometer data error problem I reported last month. It has me stumped. Time to reflect. Six weeks ago I was a wet behind the ears CAN-Bus wanna-bee developer. I still have a lot to learn but now I know something about the inner workings of a modern instrument cluster. And I'm having a blast driving my new faux ride in the office. Zero to sixty in six seconds, all from my office chair. And you can tell by the deep exhaust sound that this imaginary Mustang had its factory V6 engine swapped with a V8. Engine swaps are easy in the virtual world. Here's some photos of the finished display. I'll post videos soon. So feel free to come back and see it in action.
  12. The Arduino compatible MP3 Audio Player I ordered five weeks ago (from China) is still not here. So I gave up waiting for it and ordered the same item from Amazon. That was on Wednesday and it arrived the next day. So it wasn't long before I was hearing delightful audio from the clever little module. It's the DFPlayer Mini, a 16 pin DIP module that uses micro SD cards. It was soldered onto a small protoboard and complemented with some power filter caps. After a bit of experimentation I found that transformer coupled audio greatly improved the sound quality. So a miniature 600Ω:600Ω audio Xfmr was installed too. It sounds very good with the 2x15 Watt stereo amplifier module driving a pair of 4-inch car speakers. The DFPlayer MP3 Module is mounted on protoboard. There's an Arduino library for it, so incorporating audio capability was painless. Besides adding the software functions, several 16-bit audio files were produced in Audacity that give this bookcase exhibit a bit of character. There's attention getting V8 engine revs and fast driving audio clips. Plus an ambitious car horn for making sure pedestrians get out of the way when I recklessly "drive" around the office. The MP3 player module was the last item I needed to finish all the wiring. I'm happy to report that all the hardware assembly is complete. The bottom view. All modules are wired and working. There's a bit more software to write. But this Mustang cluster is getting close to the finish line.
  13. More parts have arrived. Not everything, but enough to put me back to work for a couple days. The IR Remote was wired to the Arduino and sprinkled with some sweet software. Now I can operate several functions from the handheld controller. As mentioned before, the instrument cluster will be a bookcase exhibit (nerd art); The remote provides another way to turn it on, rev the engine, and do other amusing activities. Besides the Ignition Key, the handheld remote can start the imaginary motor and animate the cluster gauges. The animations are table based and have 10Hz updates. So a one minute "drive" uses a table with 600 data sets. The advantage of this method is that adding new animations doesn't require rewriting code. Only the table data (gauge values stored in an array) needs to be updated. The IR Remote Receiver's PCB was removed from the sensor and replaced with a directly soldered 3-wire cable. This allows the sensor to fit at the top of the Ignition Switch / Message Center console. So the 3D printed Switch Housing was updated with a window opening for the IR sensor. Revised housing and modified IR Sensor (extended from PCB). Dashboard rear view, Ignition / Message Center Switch with preliminary wiring. Some Arduino compatible Relay and a MOSFET modules are used for programmable Power Control. Instrument Cluster and Amplifier power uses a 2-Channel relay module. The MOSFET controls the light intensity in the Message Center's push button switches. The two modules are mounted on a DiY 3D printed chassis.
  14. The ignition key switch is here. A DiY 3D printed plastic housing combines it with some nice looking push-switches for upgrading the Message Center Switch console. All the new switches are ready for the 3D printed ABS plastic housing. The housing needs sanding/paint before it's mounted on the dashboard.
  15. I don't know of anyone that has connected the Rodeo to a Smart Port R/C Rx, but that shouldn't stop you from trying. My OSD hack information shows how to access the FC's UART2: https://www.rc-cam.com/forum/index.php?/topic/4101-diy-walkera-rodeo-150-minimosd-installation/&do=findComment&comment=28599 Then you would use the CleanFlight Configuration app to configure the FC to enable the Smart Port function on UART2.
  16. Despite all the good news, there's one nagging issue. The instrument cluster has a periodic warning beep and "ODOMETER DATA ERROR" message in the Message Center Display. And instead of mileage it displays "Error mi Error" (bad odometer and trip meter data). ODOMETER DATA ERROR appears every 10 minutes. Odometer and Trip Meter show Error instead of mileage. Google provides some useful information. The Instrument Cluster has EEProm storage for the odometer data. The mileage should appear on power-up but I only see the odometer error. I wondered if it needed something from the CAN-Bus so I spent several futile hours in CAN-Bus purgatory trying to find a solution. No luck, despite threats and begging. But more digging with Google leads to some bad news. The cluster has a secrete self-test feature (button press sequence) and it detects the culprit: DTC A143 error. That's an Odometer NVM Memory Failure. The error is caused by a corrupted EEProm chip or a circuitry problem related to reading the data. I disassembled the cluster and inspected the PCB. Everything looks clean and wholesome. I did not see an EEProm Chip so I suspect the odometer data is stored inside the main microcontroller. Fixing this problem will probably involve a miracle or a deal with the devil.
  17. The CAN-Bus modules showed up in the daily mail. They were quickly wired to the Arduino MEGA 2560 R3. All three boards are mounted on a DiY 3D printed plastic chassis. Their arrival was perfect timing: It was a rainy weekend so I stayed inside and wrote Arduino software that helped me find for the missing ArbIDs. The coding effort was a success. Here's the ArbIDs to the newly discovered MS CAN-Bus (MS-CAN) items: 0x10A: Headlight Control & Backlight Intensity. 0x383: Turn Signal Indicators. 0x3B3: Warning Beeper. 0x3B8: High Beam Indicator. 0x3C1: Parking Brake Indicator, Low Brake Fluid Warning. Having all the ArbIDs was my E-ticket to building an interactive Instrument Cluster control program. Now I can enter short commands and instantly control any gauge or indicator light. For example, to set the Tachometer's RPM to 2500 I simply type TR,2500 into a serial terminal window running on my PC. The serial monitor available in the Arduino IDE is convenient, but any serial terminal program can be used. Here's a short video that shows the test program in action. As you can see, my wild pony has been tamed. Now it's time to start mounting the hardware in the oak base and write the animation code for the project's bookcase display. But some important parts (ignition key switch, Arduino MP3 player, IR Remote, etc.) are on a slow boat from the Far East. I need these things to finish the project. It seems waiting for parts is a right of passage for every one of my projects.
  18. There will be a pair of 4-inch car speakers under the instrument cluster. An Arduino MP3 player with 30W audio power amp will fill the room with the lovely sounds of a revving V8. Yes, it's become obvious that my sanity level doesn't have all four wheels on the ground. The speaker kit includes nice looking grills. But they need enclosures too. No problem, I'll DiY my own. At times like this it's nice to have a 3D printer for making custom plastic parts. I use 123D Design; It's an Autodesk CAD program that has sadly gone extinct (but I'm still a fan). DiY 3D printed speaker enclosure. There will be two speakers for the V8 motor. The 3D printed ABS plastic parts need sanding, priming, and painting. The final color will be satin black. {A bit later, after eating some dust and inhaling my quota of paint fumes ... } The rattle can painted parts look fantastic. A lot of sanding and filler primer has upgraded the rough 3D printed surfaces to a near factory made appearance. The plywood dashboard also looks good in satin black. All the fabricated parts for the display stand are ready for assembly. But none of that matters at the moment. What I really need is to get busy writing the Arduino code to control the CAN-Bus hardware that is coming from the Far East. Patience, young grasshopper.
  19. Rather than sit idle waiting for the Arduino CAN-Bus shields to arrive, I shifted over to woodworking tools. The instrument cluster will be a functioning bookcase display piece. It'll have a hollow oak base to hide the electronic parts. The instrument cluster will get a plywood "dashboard" that will either be wrapped in vinyl carbon fiber film or painted black. Just getting started. Oak base frame and plywood dashboard bezel. Oak base is assembled (test fit). 1/2" threaded rod risers with 3D printed brackets. Vintage '66 Mustang emblem badges will be installed on the base. Wood finish is Medium Oak Oil Stain and Polyurethane. There's plenty of room inside for the electronic goodies. The base is finished and looks nice. I put it aside for now since there's some painting to do on the 3D printed plastic parts. BTW, the late 1960's through 1970's was an era of faux wood grain car trim. I owned a '73 Ranchero that was factory wrapped in that stuff. The cluster's oak base is a playful tribute to Detroit's past attempts at wood grain fakery.
  20. After two late night sessions there has been more progress. The ArbIDs to the Fuel and Oil gauges have been identified. Plus those that control the door status and tire pressure monitor. I should mention that these functions are not accessible from the HS CAN-Bus. Instead, they use the companion MS CAN-Bus for communication. Unfortunately none of the online posted Ford or Mazda CAN-Bus hacker information helped find them. It was a painful exercise of manual keyboard entry and patiently watching the cluster's reaction (if any). There's over 2000 possible ArbIDs and their data payloads have some bit field dependencies that enable/disable other functions. The proverbial Needle in a Haystack. The Fuel gauge was particularly fussy to identify since the control data has weird split scaling and a unexpected control field. To make things more cruel, it would secretly go dormant for 35 seconds on some written data values. I pulled out a lot of hair while deciphering the magic data that it wanted. But I won the battle and can now fill up the tank. The Oil Pressure gauge is interesting too. It's an idiot light in the disguise of a linear display. A single bit controls it, so there's only one active position. This makes sense since the engine's oil pressure sensor is just a brainless on/off switch. Here's the ArbIDs to the newly discovered MS CAN-Bus (MS-CAN) items: 0x3A5: Tire Pressure Monitor (TPM) 0x3B1: Door Status 0x400: Fuel Gauge 0x445: Oil Pressure idiot Gauge Without a real Ford Mustang's data to sniff, my technique was brute force. I used the Microchip CAN-Bus analyzer and manually entered experimental ArbIDs and 8 byte data payloads. The data fields would be populated with test bytes (0x00, 0xFF, 0xAA, or 0x55). Then I would watch the cluster for several seconds to see if anything changed. This went on for about 15 hours, with occasional bathroom breaks. Below is a screenshot of the Microchip tool's GUI. The four ArbIDs have been configured for 1/2 tank of gas, valid oil pressure, all doors closed, and good tire pressure. There's a handful of remaining ArbID's to find. Such as: Dashboard Backlight Intensity Turn Signals (Indicator) Handbrake (Indicator) Parking Brake On warning (message center) Fuel Level Low warning (message center) DTE Data ODO Data Error (message center) Brake Fluid Level Low warning (message center) Check Charging System (message center) I'm a bit worn out from the tedious ArbID mining. Going forward I think it's best to wait for the Arduino CAN-Bus module to arrive. I can use it with some custom code that will assist me with the search for the remaining ArbID's. But the board is coming from China and I don't expect to see it for a couple weeks. In the meantime I'll build a nice looking stand for the Mustang instrument cluster. Woodworking tools won't get me greasy, so I'm good.
  21. After several hours of experimental CAN-Bus data injection I have identified a few more ArbIDs. Besides rpm and speed, I can now actuate the temperature gauge. Several indicator lights are under my control too, as follows: Overdrive Off (orange), Overheat (red), Check Engine (orange), Charge System Fault (red), Powertrain Fault (orange), Cruise Control Enabled (green), Security Enabled (red). These items are handled by two HS CAN-Bus ArbIDs (0x201 & 0x420). As follows: ArbID 0x201, with 8 byte payload The packet takes the form: [RR, rr, 00, 00, SS, ss, 00, 00] Where RRrr is the tachometer rpm and SSss is the Speed mph. The following formulas are used: rpm = 0.25 * (RRrr) - 24 Speed (mph) = 0.0065 * (SSss) - 67 Byte 0 & 1 = Tachometer rpm. See formula above. Byte 2 & 3 = Unknown. Set to zero. Byte 4 & 5 = Speed. See formula above. Byte 6 & 7 = Unknown. Set to zero. ArbID 0x420, with 8 byte payload Byte 0, Temperature Gauge: 0x55 = LOWEST Temp, 0 line 0x7F = Middle Temp 0xA0 = High Temp (top mark) 0xA1 = Max Temp (red line) with Red warning symbol (Below Tach) Byte 1, Unknown. Byte 2, Unknown. Byte 3, Unknown. Byte 4, Indicators and Temp Gauge Override: Bit 0, Unknown. Bit 1, Unknown. Bit 2, 1 = Orange O/D OFF Indicator (Below Tachometer). Bit 3, 1 = Orange O/D OFF Indicator Blinking (Bit D2 must be zero). Bit 4, 1 = Force Max Temperature (red-line gauge), no warning indicator. Bit 5, 1 = Force Max Temperature (red-line gauge), no warning indicator. Bit 6, 1 = Orange Check Engine (Below Tach). Bit 7, 1 = Orange Check Engine Blinking (Bit D6 must be zero). Byte 5, Indicators: Bit 0, Unknown. Bit 1, Unknown. Bit 2, Unknown. Bit 3, 1= Red Charge System Fault Indicator (Below Tach) Bit 4, Unknown. Bit 5, Unknown. Bit 6, Unknown. Bit 7, 1= Orange Power Train Fault Indicator (Near Tach's minimum mark). Power cycle reset! Byte 6, Indicators: Bit 0, Unknown. Bit 1, Unknown. Bit 2, Unknown. Bit 3, 1= Green Cruise Control Indicator (below Temp Gauge) Bit 4, 1= Red Security Indicator, (Below Tach). Bit 5 must be zero. Bit 5, 1= Flashing Security Indicator (Below Tach). Bit 4 must be zero. Bit 6, Unknown. Bit 7, Unknown. Byte 7, Unknown. I haven't been able to find the magic bits for the fuel and oil pressure gauges. Or for an assortment of indicators such as the hand brake, turn signals, and fluid levels. To control them I suspect I'll need a second CAN-Bus interface connected to the cluster's MS CAN-bus port. But I haven't given up on finding a way to do it through the HS CAN-Bus.
  22. It's been a good day. CAN-Bus is working and I can control the tachometer and speedometer. There's something satisfying about driving 80mph while sitting at my desk. And I have photos to prove I'm exceeding the office speed limit. 80 mph @ 4400 rpm. Oops, left the parking brake on. Despite some detours the project is moving along nicely. But there's a long ways to go. It's time to shift into overdrive and find out how to control everything else in the dashboard cluster. After I conquer all those mystery bits I can get to building what I have in mind. This Mustang cluster is going to become a working bookcase display with a key start ignition.
  23. The Mustang Instrument Cluster has arrived. It came from a wrecked car (eBay based recycler). There's some scuff marks but overall it looks good. Every part from a wrecking yard has a story. The cluster was tagged with the VIN and a online search provides a wealth of information. It was a 2009 Mustang 4.0L V6 coupe with 60K miles that had gotten sandwiched in a roadway skirmish. If by chance you were the owner of this pony when it took its last breath then please accept my condolences. And I hope everyone involved in the accident is OK. The 2009 Instrument cluster came from a pretty pony that has been put out to pasture. One of the reasons this particular cluster was chosen was because the seller's photos showed it included the harness connector plug (chopped off, with several inches of wire). I even email them before the purchase and they confirmed the connector would be included. I'm happy with the condition of the cluster I received, but the connector is missing. /* More head banging followed by silent screams. */ Without the connector plug I'm at a disadvantage. Besides the obvious reasons for wanting a factory made plug, the colored wires on it would have helped me determine the pin numbering (connector orientation). It's best to roll with the punches, so after a few minutes with an ohmmeter I have what I need. Connector orientation was determined by identifying the ground pins and matching them to a wiring list found online. Rear panel photo: Connector Pin numbering (plug orientation). Some clip-on jumper wires and a variable power supply provides good news. The cluster powers up and the six gauges successfully perform their needle calibration dance. Its voltmeter gauge is centered with the supply voltage set to 12.0V, but the other gauges are zero (as expected). All the indicators light up and backlighting is working too. The warning buzzer chirps as well. The donor organ is alive. There's a pair of wires (Pins 6 & 7) that need a 3-button Message Center switch. The switch is expensive so it's DiY time. A couple hours of experimentation determines that the switch is a resistor ladder (voltage divider) for the cluster's analog input on pin 6. The resistor values are as follows: Info: 100 Ohms Setup: 1.5K Ohms Reset: 470 Ohms Default: 100K Ohms DiY Message Center Switch, 3D Printed Bezel Green = Info, Black = Setup, Red = Reset The DiY Message Center switch is wired to the cluster and working great. I have to admit I'm not thrilled by the push-buttons; I'll swap them out with higher quality switches later on. The CAN-Bus is the next item to test. But rather than stuff more jumper wires on the naked connector I've decided to step back and solve the missing plug dilemma. Instead of complaining to the seller about the forgotten plug I decided to build my own. The cluster's connector is a 26-Pin (2 x 13) 2.54mm header. I have a female header that is 40-Pins and a close encounter with a sharp saw turns it into a suitable doppleganger. A test fit determines that the plug is difficult to install/remove in the cluster's deep opening. So I designed a 3D printed housing shell to make it an easier effort. The housing is keyed to prevent backwards plug installation. {A few hours later} All wires are soldered and safely potted in the 3D printed housing with hot melt adhesive. The DiY Cluster plug is complete. Instrument Cluster's Power/Signal plug is a 26-pin header modified to fit. See text. There's two cables terminated to the plug. One has twisted pairs for the CAN-Bus (HS CAN and MS CAN), plus some miscellaneous signals. The other has power and all the remaining signals. I won't use all the wired signals, but just in case they're all accessible. It's time to connect the Microchip CAN-Bus analyzer.
  24. The Microchip CAN-Bus Analyzer dongle arrived. It's always a pleasure to be visited by the big brown truck. I ordered the CAN-Bus tool directly from Microchip's official online store to ensure it was the latest release. Wishful thinking at best; In the box was a CD containing old V2.0 software (2011 release). So the CAN-Bus dongle hardware is probably aged like a fine wine too. I read that V2.0 wasn't compatible with Windows 10. So I downloaded the V2.3 Win10 upgrade from the Microchip web site and installed it. The app launched and I was able to setup the CAN-Bus tool. I currently don't have any Can-Bus devices to test out, but that doesn't stop me from investigating the tool's GUI. Wait a minute, the GUI's features look like someone half-hardheartedly phoned it in. It has basic functionality, but it's missing important features mentioned in the manual. For example, I can't save my tool configuration settings and there's no Trace Filter. And it's buggy too. For example, moving a trace window creates graphic ghosts that require a program exit to clear up. I found a possible explanation to these problems. The help screen reports that the PC Software is a BETA V2.2 released in 2014. That's not a good sign because the installed version is supposed to be V2.3 released in 2016. Dooh! /* Guy shakes head in frustration and mumbles to himself. */ But there's another possible reason for the missing functions. The manual states when upgrading the PC software it is necessary to re-flash the tool's two PIC18F microprocessor chips using the provided hex files. The GUI's reported firmware version numbers match the two hex file names found in the downloaded software. It appears the dongle's chips are already the latest version. But I don't trust this Microchip tool, so out comes my MPLAB ICD3 ISP Debugger/programmer. With a 12V supply connected to the CAN-Bus tool I successfully flashed both PIC chips with the provided hex files. But the firmware flashing was a wasted effort. The GUI's reported firmware version information is the same as before and the missing features are still missing. Pardon me while I take a break and try to sort this out. There's closure to this mess. I found the Release Notes file in the upgrade distribution. It confirms I have the latest PC GUI software (V2.2). It also mentions that those missing features I wanted were dropped years ago in the V2.0 release. So some functionality is now vaporware and any bugs that appear are here to stay. I've concluded that this tool is an abandoned Microchip orphan. /* More mumbling and head banging. */ If this were a product review it would be generous to give Microchip's tool a one star rating. Hopefully my opinion gets upgraded after I've done some basic CAN-Bus experiments with the Mustang instrument cluster.
  25. After a long night of web mining I'm now confident I'll be able to control the Mustang's Tachometer (RPM) and Speedometer. But everything else is still a mystery. What I unearthed is courtesy of like-minded hackers that used reverse engineering tricks. That is to say, they connected CAN-Bus sniffers to their cars and drove around while logging the real-time data. Back at home, they reviewed the timestamped activity while looking for clues on which data packets involved the dashboard. The reverse engineering task is best described as finding a needle in a haystack. But choosing the right tools eliminates a lot of drudgery. I'd like to use the sniff method too, but I don't own a late model Ford with CAN-Bus. The car in my garage was built years before this networking protocol was a Ford staple. Fortunately I found the CAN-Bus ArbIDs to the Ford Tach / Speedometer. See this sourceforge wiki: https://sourceforge.net/p/ecu/wiki/canbus/ But the search for controlling Ford's indicator lights and gauges has hit a dead end. However, during the online investigations I noticed that Mazda partially shares some of Ford's CAN-Bus arbitration codes (these two car makers have been exchanging technology). I expanded my search and found OpenGarage's list of Mazda CAN-Bus ArbID descriptors and I plan to try them: http://opengarages.org/index.php/Mazda_CAN_ID And to make things a bit more interesting, the Mustang Instrument Cluster I selected has two separate CAN-Bus ports. The HS-CAN (High Speed CAN, 500kbps) port is for the engine and drivetrain data. It provides the RPM, speed, coolant temperature, and similar data. The MS-CAN (Medium Speed CAN, 125kbps) is for ancillary information, such as fuel level, oil pressure, seat belts, parking brake, doors, etc. To fully control the cluster I'll probably need to send data to both ports. But I'm hoping that MS-CAN data is allowed to tunnel into the HS-CAN bus so that only one Arduino CAN-Bus shield is needed. /* I'll order a second shield in case my wishful thinking is cruelly trampled by reality. */
  • Create New...