Jump to content

redmist

Members
  • Posts

    61
  • Joined

  • Last visited

  • Days Won

    1

Reputation Activity

  1. Like
    redmist reacted to Adamw in Rotary fuel burn calcs.   
    With G4+ if you are using traditional mode, combining the two inj DC's as you propose is the best way to do it.  There will always be a fudge factor to apply to your calc due to deadtimes and other non-linearatites but once dialed in it works pretty well.  We used that method in Andy Duffin's RX7 when he was running in the endurance series.  If you are using modeled mode you can use the parameter "instantaneous fuel consumption" which will be a little more accurate. 
    In G4X we have added "Virtual fuel tank" functionality which covers this much better.  
  2. Like
    redmist reacted to Adamw in "Full Gear Shift Control"   
    Gear shift control strategy in G4X is pretty much the same as G4+ at present.  There is no shift actuator logic, such as a paddle shift system, it is still based around systems where the driver is moving the lever.  
    BTW, as for FTD2XX.DLL problem, it is just the latest 6.19 that is looking for that driver, but you could download 6.18 to have a look around.
  3. Like
    redmist reacted to Davidv in programmable logic   
    Yeah the transciever is miniscule though, doesnt increase footprint:
    https://www.tindie.com/products/Fusion/dual-can-bus-adapter-for-teensy-35-36/
    The refresh rate is good especially when optimized to minimize pixel writes.
    But if youre spamming it with lots of fast moving stuff or your code has a lot of unnecessary writes it can chug a bit.
    Moving over to realdash on a tablet is a whole bunch less work to be fair. But this is a learning exercise for me as much as anything else.
    The start up time, for me, is something that needs to be super snappy. Thats where a microcontroller is so good.
    I want to migrate my project to a twin core stm32 and a custom board at some point. So i wont need nextion it can control an lcd panel directly.
    But this is a huge amount of work and ive got lots to learn in the meantime.
  4. Like
    redmist reacted to Richard Hill in programmable logic   
    I moved away from using generic dash as it employs a compound CAN message, which can be a bit of a mouthful for both the ECU sending and the device receiving.  I prefer to use messages which are split over several CAN IDs such as transmit generic dash 2.  The only problem with Generic Dash 2 is there's appears to be a  bug in the non driven wheel speed (1 byte assigned, but shows as 0-1000kph, guess the text was copied from generic dash).  Not a problem though if you aren't planning on going more than 158 MPH...
  5. Like
    redmist got a reaction from Davidv in programmable logic   
    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.
  6. Like
    redmist got a reaction from Davidv in programmable logic   
    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. 

  7. Like
    redmist reacted to Davidv in Instantaneous Fuel Consumption   
    The answer is helmholtz Shooting flames with a rotary engine

    I dont think the provided instant fuel value would be much use in your scenario, because it gives a litres per km result that relies on a wheelspeed DI input for the km part of the equation.
    Which I'm imagining will be wildly inaccurate in the case of a big HP rotary driving on dirt!
    It sounds like a litres per minute figure is what you'd be after instead, you can probably get a good enough approximation of this from datalogging Effective Injector Pulsewidth.
×
×
  • Create New...