Jump to content

redmist

Members
  • Posts

    61
  • Joined

  • Last visited

  • Days Won

    1

redmist last won the day on June 9 2019

redmist had the most liked content!

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

redmist's Achievements

  1. I've currently have running on both my Link Atom and Xtreme, a low cost wireless telemetry solution using a connectionless high speed wifi network (ESPNow). While I'm currently using this for sub 20 meter high speed data (checking engine parameters while the car warms) the intent is also to run the race car dash wireless, and augment it externally with a battery powered RX8 dash (currently coding). My coding is awful, however I'd like to tidy it a little by constructing an independent CANBus config file for each of the Link CANBus configurations. Given I'm lazy, and the documentation has it in many different text formats, I wondered if there was any way to export the CANBus configuration from PC Link, or decode an LCS. An export/ LCS decode would ensure that every time I altered my CANBus config or anyone else wanted to use the code as a rudimentary base for telemetry they could alter the code base to match with relative ease. As an aside the ESPNow packets are picked up by a LoRa device for long range telemetry. The receiving end of which is both a standard WiFi AP and hosts a webpage with said data.
  2. Thanks Adam, it would appear that I'm implementing my own virtual fuel tank, without knowing Link have already done so on the G4X. I would upgrade, but until full gear shift control happens I'll stick with my storm and xtreme.
  3. I'm running a G4+ Xtreme in a rotary powered off road race car. My average fuel burn is variable based on terrain, weather, competition and how big my balls are that day. I run a couple of ESP32 devices for wireless telemetry, dash data display, data logging. I wish to integrate some code to reasonably predict the fuel remaining in tank. To this end I suspect that a simple DC primary plus DC secondary multiplied by fuel pressure will give me some indicator of fuel burned at that instant and give me a starting point for my fuel remaining figure? or are there other Link canbus variables that might better suit my purpose? Cheers, Daniel.
  4. I've noted the full gear shift control on the G4x series of ECU's. I'm currently running a G4+ Xtreme and looking at a solenoid or air shifter (would prefer solenoid as I run in rough environments and it's simpler). Given, on cursory investigation, it would appear that the G4x has some form of gear shift control it seems worth me upgrading. However I've found no documentation on this function. I'd also like someone with personal experience of the "full gear shift control" function, to comment in regards to it's use and configuration. Further, while I'm currently running PCLink G4+ (5.6.8.3671) I've attempted to also load PC Link G4x (6.19.65for docs) and it fails with of a missing FTD2XX.DLL. I can't use the recommended fix, plug in a G4x, remove and reload the USB drivers because I currently don't own a G4x. . Thanks Daniel.
  5. I dropped the Nano and went ESP32 wrover. On board can so only required an external transceiver. Picks up almost all frames. At least it's more consistent than the Nano and more than enough for a good refresh rate on the dash. Because of the "pause" between data sends the ESP will always pick up the first frames, which means the RPM is always refreshed quickly. It's dropping the occasional frame mid to late in the dataset, again not enough to bother a dash refresh. I tried lowering the transmit rate, but all that does is increase the "pause" between "burst" sends. As such it still drops frames. Only real option is to lower the data rate... and considering I'm running a AIM Evo, which is set at data rate, transmit rate and parameter set I can't alter my configuration without dropping the Evo. My Pi with PiCan2 will pick up all frames, however as soon as you burden it with an IDE the python scripts will drop frames similar to that of the ESP.
  6. I'd also like to move away from the Generic Dash to something more customized around my needs. Although I've "fudged" the generic dash such that I can display my gearbox temp, unfortunately the AIM Evo 4 that I'm currently using in the offroad race car requires that protocol. The rally car runs a G4 Storm, which by default does't appear to have a Generic Dash 2 LLC (although I'm sure I could create one). I am however having an issue with either the arduino libraries or the MCP2515 controller. Specifically it's dropping large amounts of frames from the buffer and given a small delay in the program (such as a write to the 7 Segs) it drops all but the frame 0. It's a weird timing issue as I can "count" main loop cycles in the hundreds before an can bus interrupt is generated. Might have a crack with one of my ESP8266 devices (which is sure to make everything worse).
  7. I've currently got all 6 seven segments and the 8x8 Matrix to work with Link "generic dash" can bus output. There is some work to do with my neopixel library conflicting another of my libraries, and a weird issue with my can bus adapter only picking up frame 0 or 1 when you start to introduce a delay (like writing to the 7 Segs). However given a correction of my frame issue I'm not seeing any problems with refresh from the Nano. Weird thing is the Nano will do several hundred main loops prior to picking yet another frame 0 from the buffer. Although there is a deep imprint of my keyboard in my forehead I'm enjoying battling with the cheap ahrse and very flashy intelligent 7 Segs, 8x8 and neopixels... the cheap can bus adapter... not so much.
  8. Thought the Teensy still required a can bus transceiver? If I could attach the teensy straight to my canbus then it would save me a tonne of grief!!! I've a friend that's had issues with Nextion and refresh rates, switched to a cell phone. Seems all the integrated intelligence screens struggle.
  9. Nice job David! Thank you for the pointers to Pauls well presented site. Thankyou Paul for spending the time and effort to detail such. I gather the reason people have migrated from the arduino mega/nano to the teensy (or other platform) is because it's just too slow? I suspect by the time I generate interrupts from the flappy paddles and insert new frames on the canbus I'll simply ask too much from this stupidly cheap device. My dash is currently being benched (chose a mass of 7 segments as they are bright in sunlight for the open race car), have it testing libraries and some basic code to pull frames and data from the canbus... it just needs some proto board... me to design and print a case (I'll keep away from PLA now thanks Dave!!!) and a tonne of tidying in code and wiring. Think I'll design and print the case around the ability to replace it with a Raspberry Pi Zero W. The nano seems fast enough, but does not seem reliable. I've also broken apart the canbus frames with my Pi based radio telemetry such that given the 7 segment and nanopixel libraries I shouldn't have too much issue migrating to the Pi.
  10. So David, do tell? Spill the code! After using a Raspberry pi and a small radio modem to transmit Link CAN Bus data over a serial link I've now started playing with an arduino to simply pull data off the bus and display it on a set of 4 x 7 Segments, an 8x8 matrix (gear display) and neopixel leds (RPM Limits). My coding is Uuuuuugly... but it works... mostly.
  11. G4 Storm, old case, updated for CAN. Generic Dash stream at 20Hz. Only CAN sniffer I have is the PiCAN 2 shield on my Pi 3. Three, frame 14 (0d) interspersed through my log... I've used both C and Python libraries. Given it's a correctly formatted CAN message I doubt it's generated by by PiCAN2 board. I guess I could drop the entire frame given it contains nothing? (don't want to send rubbish over radio). candump.txt
  12. Through my own stupidity, (and lack of 16 fingers) I used the wrong trigger to complete a stream of Link CAN (Generic Dash) data for my radio telemetry program. On triggering a completed set using the last frame as "d" (14), from the correct Link CANID I got an intermittent completion of the link data set (and sent via radio). On further investigation I've noted that it's only sending frame 14 once randomly every 5-10 or so seconds. This frame does not appear on the Generic Dash CAN Data Format. The 7 remaining words (including the 6 that are relevant) are all "00"'s Wondered if it was important, or if it had any data that I should be displaying either locally(dash) or remotely (transport truck). Cheers, Daniel.
  13. Cheers Adam, thanks for that. I suspect my USB serial adapter might not be doing RS232 but TTL. That and the fact that Putty is playing games with me.
  14. Have attempted to use the RS232 port with the Link configured to 12hz continuous. There isn't a squeek out of the port until such point in time as I kick up PCLink.
  15. I've an older G4 Storm that I'm benching for radio telemetry. It's simply a trial to enable both my G4+ Xtreme's to transmit radio telemetry, GPS data and alerts to a base. I've got the radio bridge working well, bridging between two USB devices (GPS and radio), and my program logs, truncates and transfers NMEA data to my second device without issue. However on switching to the Storm I've noted that the Continuous modes (12/25 hz, and CRC) don't appear to be continuous. As in without any input from PCLink the USB serial port is silent. I could emulate the PCLink "tuning" call, however the response doesn't appear to conform to the short or long datastream format listed in PCLink. On a requested short or long, should I send a capital "A" I get a hex FE (decimal 254) return, which I gather is an out of bounds error? Not that this should matter if I can get a continuous data stream. Am I being rather dense here and that the Datastream configuration only refers to the RS232 data? As an aside these are on two raspberry pi devices running Rasbian.
×
×
  • Create New...