Relee, he editado el mensaje mientras por lo visto respondías.

Sí, un problema de la consola es que el dibujado es a nivel de toda la pantalla. Esa es una de las razones por las que operar con forms es más eficiente, solo se actualiza la parte del gráfico que cambia.
Por otro lado la pantalla tiene dos barridos vertical y horizontal uno es miles de veces por segundo el otro es entre decenas y pocas centenas de veces por segundo (típicamente entre 24 y 120 por sg.).  Pués bien, si eres capaz de redibujar todo el gráfico en ese tiempo, no aparece ningún parpadeo.

Otro modo en que se palia ese efecto, es cuando el sistema dispone de un backbuffer (una memoria adicional donde vas dibujando, tarde lo que tarde, y cuando está listo se dibuja de un plumazo entero)... el peor caso es cuando se va dibujando en tiempo real, pixel a pixel, que es muy lento...
Lo cierto es que incluso aquellos antiguos monitores CRT en BN o 256 colores solían tener entre 2 y 8 páginas de vídeo, que uno podía dibujar antes de presentarla, no entiendo porqué Mocosoft, no ha provisto al menos un backbuffer adicional para la consola que luego con un simple Console.Flush o Console.Draw realizara el intercambio entre ambas páginas, incluso con un Raster Op. para dibujar (incorporar al dibujo) solo los cambios (por ejemplo).

Esto parece un problema de sincronización.
Hay dos tipos de sincronización. La que refiere al período de refresco, esto es cada vez que el puerto serie manda datos y a la interpretación de datos.
Si sucede que el puerto manda un dato que tu esperas (pongamos 450) y luego lo alterna con el envío de otro dato distinto (pongamos una señal de 'listo', con valor 0) y tu derivas ambos valores tratados como el mismo tienes ese resultado.

Sucede algo parecido cuando tu solicitas datos al puerto serie en vez de dejar que sea el puerto serie quien te los envíe. supongamos que el puerto serie envía una señal cada 200 ms. y tu pones un evento de actualización cada 100 ms. pués una de dos veces obtendrás el valor real y en la otra podrías obtener un valor temporal, si sucede que el dato no está listo, pero el dispositivo sigue funcionando con otros datos.

Es dífícil de determinar el problema exacto, pues requiere documentación del dispositivo y realizar pruebas específicas para determinar que tu programa cumple lo que la documentación señala y que el propio dispositivo también cumple  lo que la propia documentación señala (a veces puede haber un bug en la documentación o se hicieron cambios de última hora que no se refleja en la documentación).

Una de las cosas que puedes hacer es bajar la velocidad de refresco (por ejemplo de 100 a 200ms), y ver si se soluciona ese parpadeo, o por lo menos mejora.
Otra es interponer una propiedad que verifique diferencias entre el valor actual (recibido y el previo) y descartar el cambio si está por encima de cierto umbral... digamos que el dispositivo tiene flucturaciones que no están estabilizadas...

El siguiente pseudocódifgo trata de paliar ese efecto, naturalmente es un punto de partida, tendrás que afinarlo hasta que veas que resulta satisfactorio.
La idea es la siguiente. Partamos del hecho de que un voltaje es x (2'2 por ejemplo) y que la transicion entre ese valor y 0 precisare de 1sg. si resulta que el refresco es cada 100ms. podríamos establecer que la tasa de cambio por refrsco no debería ser mayor (nota que solo es una aproximación teórica) a tc = 2'2 / (1000/10). Es decir en cada refresco el valor no debería cambiar más de 0'22v. respecto del actual...

Y eso debería como mímino limitar los picos de transicion entre estados...

Nota que 'tasaCambio' es un valor de umbral que dentro del mismo acepta el cambio y alejado del mismo rechaza el cambio... en el siguiente evento, si la tendencia continúa, señala que es indicador de que el cambio recibido antes puede ser real... entonces se puede añadir una segunda oportunidad de cambio... ojo, te la comento, de entrada, si no funciona bien del todo, entonces descomenta ese código y habría que ponderarlo...

Es más que probable que deba ser afinado, tasaCambio podría ser ponderdado por un factor constante... (mayor o menos que 1) por ejemplo:
Igualmente el intervalo de refresco y el plazo tomado (son válidos si el sistema es fijo, no es válido si no hay eventos a intervalos fijos, en ese caso debe tomarse una media de eventos por minuto (por ejemplo).
Que funcione del todo bien, va a depender de cuanto se aproxime al funcionamiento del dispositivo.

Ya te respondí en el otro lado, aunque este es una ubicación más propicia... me cito:


Explorer está abierto por defecto, desde el momento en que aparece el 'desktop. es la ventana 0, las siguientes instancias de explorer abren el arbol de directorios de ficheros.

Las normas prohíben crear multiples mensajes con el mismo tema.

En el otro hilo ya te respondí a la segunda parte (que es lo que preguntabas allí). Amplía la pregunta si necesitas más.

Es explorer.exe

---

Amplío aquí la segunda pregunta que haces en otro sitio...

La ventana 'Run', es una ventana de Explorer, aparece cuando se pulsa ciertas combinaciones de teclas, luego no hay forma establecida para que desde Batch, puedas abrirla directamente.

Lo que no quitas que puedas enviar las pulsaciones de teclas con un sendkeys, dentro de cualquier miniprograma cuyo cometido sea precisamente ese y al que tu invocas.

La consola no dispone de un objeto 'Font' para poder cambiarlo.
La causa obedece a que esas son propiedades compartidas por todo el sistema (como la fecha, hora, etc...), no es local a tu aplicación, y por ende, es preferible que sea algo que el usuario (el consumidor de su equipo), configure y cambie a su gusto (no al gusto del programador).

Si necesitas personalizar ciertos detalles entonces tira de windows.forms (que para eso está)... ahí es el programador quien 'manda' sobre las ventanas de su aplicación.

Y si pones un tamaño de letra de 200 o la tinta del mismo color que el fondo, es cosa tuya... Esto mismo en la consola, puede dar problemas cuando el usuario abra otra aplicación (que no sea la tuya) que haga uso de la consola y resulte que 'no ve nada', aunque parece estar funcionando bien... o le aparece todo en caracteres chinos o ilegibles.

Creo que está bien claro.

Si el error que marca es 'overflow', implica que el string que quieres convertir a entero de 4 bytes, tiene más bytes que los caben en un int32... No hay solucion, más que quitar bytes hasta que no marque overflow, o directamente tomar solo 4 de ellos de la posición que interese, o bien utilizar un int64 (tendrás el mismo problemas si el string supera los 8 bytes).

Antes de preguntar, por que no haces un 'trace' del error?. Con un simple messagebox.show(recibidos) podrías llegar a ver el contenido de dicho string (si tiene caracteres no imprimibles, presenta el valor de los bytes. Es más ejecutando paso a paso, párate en el string 'recibidos', posiciona el cursor y espera un instante, el 'intellisense', mostrará el valor del string.

Para los errores léxicos o sintácticos, tienes que recurrir al lenguaje. Esto es pulsa F2, y localizas el objeto y método que marca el error (en este caso int 32, o mejor Convert), en la descricpión del mismo aparecerán los posibles errores que pueden darse y la causa del problema. En cualquier caso todos esos errores, debiera uno resolverlos con el IDE o la ayuda en linea (si no está instalada localmente en el equipo), de la pagina de Mocosoft... O bien con libros que explican bien.

Las preguntas que cabe hacer son las semánticas... esto es, cuando quieres hacer una cosa y 'te sale' otra o no te sale nada... o uno no tiene idea de por dondede tirar, o uno tiene demasiadas ideas por donde tirar, pero no tiene claro cual sería preferible. Este tipo de problemas no suelen resolverse con consultas a la ayuda (aunque algún código de ejemplo puede que sí ayude, si se llega a dar con el adecuado que coincida exactamente con tu caso) o al manual del programador...

Yo creo que más que 'velociraptor', es un 'vecinotontor', disfrazado para la ocasión (por ser de noche, si fuera de día se podría asumir que fuera la 'mascota' de algún equipo de algún deporte)...

Son matemáticas simples...

Todo aquel que se dedique a programar, una de las primeras cosas que debiera aprender es precisamente a operar con bits...

En NET (y otro muchos lenguajes), que aceptan operaciones de desplazamiento (heredadas del ensamblador), resultan más sencillas (y veloces)... aqui resuelto con division.



235 = bin: 1110.1011                                      
Bitset(235, 3, 4) Resultado 13  
marcando la separacion de bits filtrados: 1'1101'011
Los 3 bits de menor peso, se pierden al dividir por 8.
El bit alto se pierde al enmascarar con 15: (11101 and 1111)

p.d.: en tu caso como precisas los bits 5 y 6

Si al final harás lo que te dice AlbertoBSD (interponer un PC entre el router y el resto de la red), la opción que te indiqué sigue válida sobre la mesa...