Release 0.1.1 (long post and picture heavy)

[jbelanger]

There is a new release available for the IOx. The firmware is available here and the ini file is available here. An msq with the default settings is available here.

Since there are quite a few changes since the last release and there are quite a few possible combinations (as you can see below), it is possible that there are still some bugs present. I have tested each features with many test cases and combinations but a full coverage is practically impossible since there will be differences depending on which devices are connected to the CAN bus. So use some caution when you use a new feature for the first time with a new setup.

This release introduces quite a few new features. As you can see from the new menu, there are now 4 generic PWM outputs, a push button start feature, programmable on/off outputs (with the option of selecting which outputs are used), and CAN broadcasting. Also, all the PWM outputs can be set to output a signal that is compatible with an RC servo.



The generic PWM outputs allow you to select any of the IOx data as the load. The load can also be selected as any of the MS (MS2 or MS3) data or any other CAN device connected to the CAN bus and which is part of the same TunerStudio project. The duty cycle can be defined in an 8x8 table with the load as a function of RPM (the RPM is assumed to be from an MS with a CAN ID of 0) or as a 16 entry array. The output port can be any of the 8 channels from timer 1 and timer 2 (PTD0-7). You can also set the output signal to be compatible with an RC servo.







The push button start feature has been ported from the TinyIOx and is discussed here: http://forum.jbperf.com/viewtopic.php?f=9&t=1195#p6043.



The programmable on/off outputs are similar to what is available on the MS2 and MS3 (spare ports). The difference is that there are 8 outputs which can be selected to be any of the available outputs on the IOx, there are 3 conditions for each output and you can select the output channel from any controller on the CAN bus (as long as they are part of the TunerStudio project).




The CAN broadcasting allows the IOx to broadcast up to 8 frames 20 times per second. This is intended to be use with non-MS device which need to get some IOx data. The frame ID is defined from 4 bytes in hexadecimal which allows each frame to be an 11-bit or 29-bit ID of any value. If this is used with other MS protocol compatible devices on the CAN bus, care should be taken when selecting a frame ID so that there is no conflict with the MS protocol.




The way to set some PWM output as an RC servo signal involves setting the frequency of the timer corresponding to the output to 50Hz: this automatically sets the prescale (8) and frequency divider (233) to get a 50Hz frequency that allows the best accuracy for the RC servo signal. All the PWM outputs using a timer set like this but without the RC servo setting will have a normal 50Hz output that varies from 0 to 100%. Each specific PWM output needs to set as an RC servo signal as shown in the generic PWM outputs above and as shown below in the port settings (for MS2/Extra) and PWM outputs (for MS3).





Jean

[Sanec]

Downloaded and flashed - works, I will deal with the settings.
add there would still tune inputs to different sensors and computation speed of the pulse number. can add more speed. I now use it to check the operation of the pressure regulator and fuel pump under a boost.

[masterx81]

Thanks jean!!!
So i can set the generic pwm without use the ms3 features (so i have them free for other usage), based only on iox?
Nice work!!!
I test it immediately

[Rod S]

Jean,

In the section for the RC servo PWM signal, the first screenshot shows timer 2 selected, the third screenshot shows timer 2, PTD0, but the middle screenshot shows timer 1, channel 3, PTD5.

Are the screenshots un-related (to each other) or am I missing something important here (difference between MS2 and MS3 perhaps as I'm not familiar with the latter) ?

Rod.

(edit, added a bit)

[jbelanger]

Rod,

All the screenshots were taken to show examples but I can see how that could be confusing when seen together. To be able to set thing as per the second screenshot the base settings would need to be such that timer 1 is set for an RC servo frequency.

Jean

[masterx81]

Using the new generic pwm, i suppose that when the load axis is from an iox input i must use an ADC value, right? Or is a voltage value?

[jbelanger]

Yes, the load for analog inputs will always be in raw ADC counts.

[masterx81]

I'm using the generic pwm for some gauges... Wow, amazing work!!! All seem work as it shuld.
Only one question: The resolution of the pwm is in 0.3/0.4 steps, can't be more? Or is a limit of the hardware?
I ask this because sending the dac signal to the gauge at high temperatures the change in voltage is really small. The gauge is a stepper one, with a classic ntc sensor. I'm using 46khz pwm, i can reduce it a bit if i can gain resolution...
As my gauge show only from 50 to 150 (few mv to 1v) i've already used a voltage divider for have a 0-1v signal from the 0-5v signal of the pwm....
For reference at 150° i have a dc of 7.4%, at 145° a dc of 9.0, and are only 4 "dc steps" away. Hope to not go as high with oil temp

[jbelanger]

The problem is that the duty cycle is defined as a single byte so it has a range of 0-255. The best resolution is therefore 1/255=0.00392156 which is about 0.4%. Please note that this is better than on the MS3 where the duty cycle has a range of 0-100 with no decimal value (for the generic PWM outputs).

Using more resolution would require using a 16-bit duty cycle. That is not practical because that would double the memory requirements and that would increase computations a lot for the interpolation in the table since this is an 8-bit processor.

Jean

[masterx81]

The pwm out of the iox is WAY better that the ms3! Frequency can go as high as 100khz, lol With a 250hz signal a dac in nearly inpossible with a good response and good ripple. IOX is the only way, plus a ton af ADC... So nice
Ok, i'll use it as it, is enough precise, and i hope to not see NEVER more than 130°c of oil temperature (that in any case from 125 to 130 are always 4 steps...)

[jbelanger]

Can you post a screenshot of your duty cycle table(s) or post your msq? I'd like to see what it looks like.

Jean

[jbelanger]

Actually, I'm thinking there might be a possibility for the curve which I assume is what you're using. Since the curve only use 16 entries instead of the 64 entries of the full table, using a 16-bit value would not have an impact on memory requirements. I'll have to check about the interpolation but that is also simpler for the curve so doing it for 16-bit values may not be an issue. However, you would have much fewer frequency options (but still up to 93.75kHz).

Jean

[masterx81]

If you prefer i can send you the msq This is the oil temperature.
It's nice to have a gauge that show EXACTLY the same as the ecu, the stepper movement ensures precision I've used 'chinese' prosport/r spec/depo/etc gauges (with your iox they become REALLY precise On the turbo pressure i can see the needle move for a variation of max 2kpa . If someone wants more details, i have the curve of the sensors and of the gauges

EDIT
The oil temp is 150, 145, 140, 135, 130, 125, 120, 115, 110, 105, 100, 90, 80, 70, 60, 50*c. And the dac out goes into an opamp rail-to-rail buffer, then into a 15k/3.3k voltage divider, and finally into another buffer (ts922) to the gauge.

[masterx81]

Actually, I'm thinking there might be a possibility for the curve which I assume is what you're using. Since the curve only use 16 entries instead of the 64 entries of the full table, using a 16-bit value would not have an impact on memory requirements. I'll have to check about the interpolation but that is also simpler for the curve so doing it for 16-bit values may not be an issue. However, you would have much fewer frequency options (but still up to 93.75kHz).

Jean

This would be great! For the frequency, if there is a change from the actual 46khz that i'm using i need only to recalculate and change the 4 components of the 2nd order dac (2 resistors and 2 capacitors).
This mcu doesn't reduce the pwm resolution with high frequencies? if i well remember the pic mcu that i've used in the past had some limitations in frequency vs pwm resolution...

[jbelanger]

You're right. I was a bit too quick with my comment. You would still get a 93.75kHz but you would also be using only 8 bits so you would still have 0.4% resolution. Those are the maximum frequencies with the resolution and the number of bits used:

Code: Select all

  Frequency    Resolution # bits used

  93750         0.39063%      8
  46875         0.19532%      9
  23437.5       0.09766%     10
  11718.75      0.04883%     11
   5859.375     0.02441%     12
   2929.6875    0.01221%     13
   1464.84375   0.00610%     14
   732.421875   0.00305%     15
   366.2109375  0.00153%     16

There are other possible frequencies when using other prescale value but they are all lower than these for the same resolution (number of bits used). So if you wanted to keep the 46kHz frequency you would only have 0.2% resolution.

I still think it is useful to have so I will look into implementing this.

[masterx81]

With the actual DAC i have an 1ms response time with 2.4mv ripple, maybe it will be ok also with 23khz reducing response time or increasing ripple. I think that also on the tunerstudio table isn't pratical to go over the 0.1 resolution (dc from 0.0 to 100.0 in step of 0.1), that is nearly 10 bit resolution. I think that is sufficient for most of the users (but little waste in memory as we eat 2 bytes for only a 10 bit value...)
In any case also 0.2% will be twice the resolution that i have now, so instead o 8 step i get 16 step for 10*c, that quite for sure will be more that enough to not see any strange movement of the needle.

[masterx81]

Another question: It's possible to have 12 bit accuracy on iox usage and send to the ms2/ms3 the 10 bit default value? I think that will be quite easy to implement with a bitshift of the 2 lsb...
EDIT
I'm asking for this because if you look my curve i have small adc accuracy at really high temperatures, and i've already halfed the bias resistor (2 2490 in parallel, this give me a good resolution over all the temperature range -20°c to 150°c, i can't do more that this as for oil temp i'm using the same sensor as per clt, and i need a bit of accuracy on cold climates)

[jbelanger]

The shift is easy but that would mean that it would have to be done when being transferred to the MS3 because the data is stored as it is read from the ADC and that's what the MS3 reads. But if I do the shift when transferred over CAN then that would also be done when TS reads the data which would mean you don't see the same thing in TS or datalogs as what the IOx sees.

The real solution is to have the MS3 accept 12-bit data and let the user tell the MS3 that the data is 10 or 12-bit. You could make a request on the msextra forum.

By the way, if you don't actually use any of the ADC data on the MS3, you can simply set the ADC accuracy to 12 bits in the ADC settings.

Jean

[masterx81]

I'm sending the oil temp information to the ms for logging (and also temeprature ecu, variable launch, oil pressure and accelerometer data), so i need the reading in the ms box...

And storing the 10bit 'shifted' version in an another set of variables (or array)? Will double the space requirement in memory...

Yes, the real solution will be use 12bit in ms, maybe i'll open a thread on ms3 development. But the ms3 hw il capable of 12 bit accuracy?

[jbelanger]

The main issue with using 12-bit values on the MS3 is the size of the calibration tables: that would mean tables 4 times as big (4k or 8k instead of 1k or 2k). If it's only for logging purposes using the generic sensors, I think you can use the 12-bit values but you may have to "cheat" with the calibration.

Jean