Running your test code and capturing millis gives me a time of ~28ms to run getTempCByIndex, so there indeed is your delay. Sounds like you need some external latching in hardware to hold values for the nixie, although at this point, I can't envisage how it's set up to require such constant updates.

yes i know that with hardware latching i resolve, there is no way for create a software latch ?

noob question (i came from electronic world, do not have sw base): when a variable await from data (like my "temp") it is not accessible from micro ? why the arduino serial do not send a 0 Zero, during this 28ms ?

Not sure I really understand the question, but the arduino serial print commands are not asynchronous i.e. when you call them, they block until all data you gave them has been sent to the serial port. So when the getTempCByIndex routine is running, there will be no outbound traffic on the serial port.

So only the delayMIcroseconds in the handshake needed for getTempC take at least 14.4 ms. That is allready 70% of the 20 ms you wait. So only 30% of the time it is executing code. During all this IO it continuously clears and sets the interrupt bit, so it won't miss a bit.

Some possible tweaks to increase speed (all disclaimers apply I have not tested this!)

1) remove the last _wire->reset(); from readScratchpad(), ==> win 1.5 millis think this is quite save as all functions reset the wire at their start

AFAIK sending the _wire->select(deviceAddress); is needed even with one sensor, otherwise another 5.4 millis might be won. (** in code above)

From the DS18B20 datasheet, page 11

SKIP ROM [CCh] The master can use this command to address all devices on the bus simultaneously without sending out any ROM code information. For example, the master can make all DS18B20s on the bus perform simultaneous temperature conversions by issuing a Skip ROM command followed by a Convert T [44h] command. Note that the Read Scratchpad [BEh] command can follow the Skip ROM command only if there is a single slave device on the bus. In this case, time is saved by allowing the master to read from the slave without sending the device's 64-bit ROM code. A Skip ROM command followed by a Read Scratchpad command will cause a data collision on the bus if there is more than one slave since multiple devices will attempt to transmit data simultaneously.

READ SCRATCHPAD [BEh] This command allows the master to read the contents of the scratchpad. The data transfer starts with the least significant bit of byte 0 and continues through the scratchpad until the 9th byte (byte 8 - CRC) is read. The master may issue a reset to terminate reading at any time if only part of the scratchpad data is needed.

So the protocol may be screwed less than thought before if you do a reset() And as all functions start with a onewire->reset() this seems to be solved.

Single device can be tested with with getDeviceCount() ==> optional use the device address)

Combined with my prev post void readScratchPadFast for a single device could become: