Nistune Forums

ok, i select a part of a fuel map for example, while i have the sonsult panel open, and i hit the key "+" few times, i recive a message that the update que is full i hit the ok button and afther that the consult windows is does not receive any new data, i close it i open it again, same thing noconsult data available, i disconect from type 1 board (by hiting the consult button in the upper right corner of teh screen, i conect back to the type 1 board, and open teh consult window, and now data is updated and keep beeing updated in the consult window)

There is currently an 'enhancement' CR open for this issue

What happens is that USB transfers data in packets. for fast upload it is best to transfer larger sized chunks. However some ECUs such as the early model Z31 only have 256 bytes of RAM in the HD6802.... Of which there is only 16 bytes free for NIStune to use for its consult buffering. So our data transfer rate is limited by this lower end ECU

Currently when more than 1 cell is selected, 16 x buffers (of 16 bytes) are uploaded for a single update

Hold a +/- key down and suddenly you are pushing 256 byte updates over the interface for each key press

Obviously i need to make this more efficient, similar to serial consult where I queue the memory addresses to be changed and then only ovewrite those cells which have not been uploaded yet, and only the update buffer groups that need to be updated

What happens is that holding the +/- on the USB version will fill up the current buffer queue and then it becomes too much for the comms interface to handle and it disconnects

For now do the changes gradually or one cell at a time. It is a known issue and probably needs about a day of design, code and testing to properly implement it to make it work better

i'm not taliking about, the upload beeing slow or the size of the que, the problem is that you hit + for example many times, without receiving the mesage that the que is full, in this case data is beeing sent to the ecu and during the data send the consult display is not updated but as soon as data transfer is finished the consult display start to receive updates again,

until now no problem - the problem is that afther you receive the message that the transfer que is full, the consult display will not receive updates anymore (you have to disconect and reconect from the consult in order to make the display receive updates again)

Whilst updates are being performed, requests for streaming are halted until updates are complete (so the updates can be finished)

ie Updates are higher priority than streaming data

Optimising the queuing of information will speed up the updates, so you will get streaming back sooner

If the consult queue is full then it should continue to receive streaming. It is probably in an internal error state. I'll raise a CR for this and look into it

Please let me know if this is still and issue, but with the buffering, should be solved now

Bit OT, Matt I can see your on a mission, I am looking forward to the next update...