#112 Gracias por el comentario, bastante interesante para un teleco.

#111 Supongo que habilitarán una web para asociar el IMSI/IMEI a tu matrícula y/o dni.
El DNI no es muy práctico por que bien puedes dejar tu coche a alguien o tengas un coche de alquiler, pero bueno no me hagas mucho caso con la legislación.

#90 Pues eso del apagado pasivo es una tontería. Si el dispositivo no responde a la red lo quitas de la tabla de la BTS y listo. Menudos pijoteros.

#105 Cuando trabajas con módulos de radio el mayor problema que te puedes encontrar es el consumo de batería, es muy elevado y esto hace que los dipositivos portatiles tengan poca duración de batería. Las tecnologías NB-IoT y LTE vienen a solucionar este problema. A grandes rasgos, la idea es que el estado "deep sleep" del modem de radio, lo que hace que consuma poca batería, es gestionado directamente por la celda de la red, y no por el microcontrolador. Se utilizan servidores remotos UDP (no TCP) y los mensajes no los envías directamente a este servidor desde el modem de radio, si no que se los guarda la antena y los envía ella cuando considera.

El apagado pasivo es porque el operador quiere que desactives el modo "deep sleep" de la antena, antes de apagar el modem, de este modo liberas tus slots en la celda de red. La medida que han tomado es que si pasada una hora tu no generas actividad en la red, entonces se te expulsa directamente.

#112 Gracias por el comentario, bastante interesante para un teleco.

#90 ¡Gracias de nuevo!

Lo de tardar 100 segundos en empezar a comunicar la posición, ¿es fruto de la especificación o consecuencia del intervalo posterior entre comunicaciones? Vaya, ¿es porque empieza el contador cuando se enciende y se usa la misma instrucción para enviar la primera localización que las demás?

#123 Cuando enciendes el dispositivo tienes que esperar un tiempo antes de encender los módulos de radio y GPS porque no sabes si el usuario simplemente está jugueteando con el aparato, y tu tienes la necesidad de ahorra batería al máximo (el encendido de los módulos tiene un coste de batería alto). Tras 100 segundos se entiende que hay emergencia y se activa la radio y GPS. Creo que en la norma ahora mismo no hay nada referente a esto. En cualquier caso es un comportamiento lógico que tu mismo te das cuenta cuando haces las pruebas para testear el producto.

#80 Muchas gracias por toda la info, es muy enriquecedor. Ya que estamos, aprovecho para seguir curioseando...

¿Cómo habéis diseñado el gatillo que activa el modo de emergencia? ¿Es físico, detecta la alteración que produce el colocarlo sobre el coche?

#84 A nivel de hardware el dispositivo es relativamente sencillo. El encendido se realiza mediante movimiento mecánico, es decir, coges con una mano la cúpula y con la otra la base, y realizas un giro como si estuvieras habriendo una tapa de un bote ancho. Automáticamente se encienden los leds. A los 100 segundos se encenderán el modulo de radio y el GPS para empezar a transmitir, y transmitirá un mensaje de posición cada 100 segundos. No se incluye ningún sensor que pueda detectar la posición o el movimiento del dispositivo. Vamos que es tonto, tu lo enciendes, el empieza a enviar datos (a día de hoy solo a nuestro server) y cuando quieras lo apagas y deja de funcionar. Más curiosidades: aquí un operador (no digo el nombre...) nos hizo la jugada del quince, porque una vez ya teniamos el dispositovo fabricado nos exigían un apagado pasivo, esto quiere decir que primero se tenía que hacer una desconexión de la red, y luego apagar la electrónica. Nuestro diseño simple, mecánico, impedía que pudieramos hacer esto y obligaba a tirar a la basura una gran inversión ya realizada. Al final se nos dio la certificación, pero exigiendo compromiso de cambio en las próximas unidades.

#90 Pues eso del apagado pasivo es una tontería. Si el dispositivo no responde a la red lo quitas de la tabla de la BTS y listo. Menudos pijoteros.

#105 Cuando trabajas con módulos de radio el mayor problema que te puedes encontrar es el consumo de batería, es muy elevado y esto hace que los dipositivos portatiles tengan poca duración de batería. Las tecnologías NB-IoT y LTE vienen a solucionar este problema. A grandes rasgos, la idea es que el estado "deep sleep" del modem de radio, lo que hace que consuma poca batería, es gestionado directamente por la celda de la red, y no por el microcontrolador. Se utilizan servidores remotos UDP (no TCP) y los mensajes no los envías directamente a este servidor desde el modem de radio, si no que se los guarda la antena y los envía ella cuando considera.

El apagado pasivo es porque el operador quiere que desactives el modo "deep sleep" de la antena, antes de apagar el modem, de este modo liberas tus slots en la celda de red. La medida que han tomado es que si pasada una hora tu no generas actividad en la red, entonces se te expulsa directamente.

#112 Gracias por el comentario, bastante interesante para un teleco.

#90 ¡Gracias de nuevo!

Lo de tardar 100 segundos en empezar a comunicar la posición, ¿es fruto de la especificación o consecuencia del intervalo posterior entre comunicaciones? Vaya, ¿es porque empieza el contador cuando se enciende y se usa la misma instrucción para enviar la primera localización que las demás?

#123 Cuando enciendes el dispositivo tienes que esperar un tiempo antes de encender los módulos de radio y GPS porque no sabes si el usuario simplemente está jugueteando con el aparato, y tu tienes la necesidad de ahorra batería al máximo (el encendido de los módulos tiene un coste de batería alto). Tras 100 segundos se entiende que hay emergencia y se activa la radio y GPS. Creo que en la norma ahora mismo no hay nada referente a esto. En cualquier caso es un comportamiento lógico que tu mismo te das cuenta cuando haces las pruebas para testear el producto.

#45 Gracias por la info, y se sabe ya si la idea es mantenerlo conectado 24/7 y que la DGT nos tenga geolocalizados, o es para activaciones puntuales en caso de accidente?

#70 Por supuesto, para casos puntuales. Aquí no hay trampa ni cartón, por lo menos en los dispositivos de mi empresa, donde he dirigido el desarrollo del firmware.

La idea es que la garantía de un dispositivo sea de 10 años (esto lo exige la DGT a los fabricantes). Esto no quiere decir que la batería dure 10 años, el uso continúo del dispositivo puede tener una duración de 4/5 horas con una batería de 9v. Lo que más batería consume son los leds. El modem de radio utiliza tecnología NB-IoT o LTE, lo que viene a sustituir el antiguo GPRS de toda la vida y a convivir con el 5G. Estas tecnologías tienen un consumo infimo, del orden de microamperios. Sin los leds el dispositivo podría aguantar varios días.

En cualquier caso todo lo que digo es bajo mi experiencia, y teniendo en cuenta que esto está empezando y a saber como queda la cosa en 2026.

#80 Muchas gracias por toda la info, es muy enriquecedor. Ya que estamos, aprovecho para seguir curioseando...

¿Cómo habéis diseñado el gatillo que activa el modo de emergencia? ¿Es físico, detecta la alteración que produce el colocarlo sobre el coche?

#84 A nivel de hardware el dispositivo es relativamente sencillo. El encendido se realiza mediante movimiento mecánico, es decir, coges con una mano la cúpula y con la otra la base, y realizas un giro como si estuvieras habriendo una tapa de un bote ancho. Automáticamente se encienden los leds. A los 100 segundos se encenderán el modulo de radio y el GPS para empezar a transmitir, y transmitirá un mensaje de posición cada 100 segundos. No se incluye ningún sensor que pueda detectar la posición o el movimiento del dispositivo. Vamos que es tonto, tu lo enciendes, el empieza a enviar datos (a día de hoy solo a nuestro server) y cuando quieras lo apagas y deja de funcionar. Más curiosidades: aquí un operador (no digo el nombre...) nos hizo la jugada del quince, porque una vez ya teniamos el dispositovo fabricado nos exigían un apagado pasivo, esto quiere decir que primero se tenía que hacer una desconexión de la red, y luego apagar la electrónica. Nuestro diseño simple, mecánico, impedía que pudieramos hacer esto y obligaba a tirar a la basura una gran inversión ya realizada. Al final se nos dio la certificación, pero exigiendo compromiso de cambio en las próximas unidades.

#90 Pues eso del apagado pasivo es una tontería. Si el dispositivo no responde a la red lo quitas de la tabla de la BTS y listo. Menudos pijoteros.

#105 Cuando trabajas con módulos de radio el mayor problema que te puedes encontrar es el consumo de batería, es muy elevado y esto hace que los dipositivos portatiles tengan poca duración de batería. Las tecnologías NB-IoT y LTE vienen a solucionar este problema. A grandes rasgos, la idea es que el estado "deep sleep" del modem de radio, lo que hace que consuma poca batería, es gestionado directamente por la celda de la red, y no por el microcontrolador. Se utilizan servidores remotos UDP (no TCP) y los mensajes no los envías directamente a este servidor desde el modem de radio, si no que se los guarda la antena y los envía ella cuando considera.

El apagado pasivo es porque el operador quiere que desactives el modo "deep sleep" de la antena, antes de apagar el modem, de este modo liberas tus slots en la celda de red. La medida que han tomado es que si pasada una hora tu no generas actividad en la red, entonces se te expulsa directamente.

#90 ¡Gracias de nuevo!

Lo de tardar 100 segundos en empezar a comunicar la posición, ¿es fruto de la especificación o consecuencia del intervalo posterior entre comunicaciones? Vaya, ¿es porque empieza el contador cuando se enciende y se usa la misma instrucción para enviar la primera localización que las demás?

#123 Cuando enciendes el dispositivo tienes que esperar un tiempo antes de encender los módulos de radio y GPS porque no sabes si el usuario simplemente está jugueteando con el aparato, y tu tienes la necesidad de ahorra batería al máximo (el encendido de los módulos tiene un coste de batería alto). Tras 100 segundos se entiende que hay emergencia y se activa la radio y GPS. Creo que en la norma ahora mismo no hay nada referente a esto. En cualquier caso es un comportamiento lógico que tu mismo te das cuenta cuando haces las pruebas para testear el producto.

#45 Gran info! Podrias decir que datos transmite a la dgt? ( Geolocalizacion o algo mas) Como se identifica con tu vehiculo?

#101 Los datos que se envían son principalmente geolocalización (latitud, longitud y altura) y datos de la celda de red. Los datos de celda son necesarios porque si te quedas tirado dentro de un tunel el GPS no sirve de nada y con los datos de celda se puede averiguar tu geoposición estimada.

Además de eso se incluye info de la version de software, protocolo y hardware y el IMEI y el IMSI de la tarjeta de SIM. Aquí la cosa es que si tu, cuando compras el dispositivo, no se te toma nota de tu IMSI/IMEI y tu DNI, entonces el dispositivo no sabe quien es el propietario humano, ni tampoco la DGT. Es como un teléfono móvil. Si tienes una SIM tiene que haber un papeleo por medio que relacione tu DNI con la SIM, de tal modo que se te asigne a ti como persona física. Si las luces led se venden en el carrefour dudo que estos se tomen la molestia de rellenar un papelito con el DNI y el IMEI y enviarlo a la DGT. Por lo tanto, según veo ahora mismo, los dispositivos son anónimos. Veremos si la norma cambia de aquí a 2026.

En nuestro caso las líneas de teléfono de nuestros dispositivos están a nombre de mi empresa. Es decir nosotros llegamos a un acuerdo de compra con las operadoras (acuerdos de miles/millones de líneas) y la verdad que no tengo ni puta idea de como será en el futuro la relación de mi empresa con la operadora y las líneas contratadas.

#111 Supongo que habilitarán una web para asociar el IMSI/IMEI a tu matrícula y/o dni.
El DNI no es muy práctico por que bien puedes dejar tu coche a alguien o tengas un coche de alquiler, pero bueno no me hagas mucho caso con la legislación.

#6 Si, se leer. Y en catalán, también. Y si, sé ver que es una campaña de concienciación o algo similar. Y creo que es obvio lo que es....Y creo que es tambien obvio que no es solo errónea, sino sensacionalista.

#5 Depende. Si tiras de compilador nativo tienes que hacer más trabajo. Si es algo tipo .NET, Java o parecido, no, aunque el resultado puede no ser igual de rápido.

#2 ¿Que hay más usuarios de Linux que de macOS? ¿Estás seguro de eso?

#2 Mi comentario venía porque el echo de que un programa te permita hacer desarrollo multiplataforma no quiere decir que valga un chasquido de dedos pata tener tus binarios compilados en 3 entornos distintos y a funcionar. La empresa tiene que hacer mayores esfuerzos para publicar tres binarios que dos, osease gastarse más dinero en conseguir que su producto salga al mercado.

#5 Depende. Si tiras de compilador nativo tienes que hacer más trabajo. Si es algo tipo .NET, Java o parecido, no, aunque el resultado puede no ser igual de rápido.

#2 ¿Me puedes decir dónde descargar el cliente para mac?

#13@Arkhaan De verdad que me interesa mucho lo de MTG Arena para Mac. ¿Es una beta privada?

#5 -> N

#9 -> O

#10 -> M

#13 -> A

#4 Pues va a ser ese en cualquier caso, no me molan nada esos sitios.

#13 Sal y echa curriculums por ahí, busca trabajo y verás que la explotación y la misería es el pan de cada dia para demasiadas familias que solo quieren sobrevivir, eso si que es TERRORISMO

#19 Aquí cada cual llama terrorismo lo que le interesa. Cada cosa por su nombre, por favor.

#19 No te lo voy a negar, pero esto me parece exagerado además de la fuente tan fiable que lo publica...

#4 #5 #6 JavaScript es con diferencia el lenguaje más divertido con el que he programado, todo está pensado para que puedas programar muy rápido y que cualquier idea loca que tengas la puedas escribir en un par de líneas, sintiéndote el dios de la programación (esto debe sonar muy nerd para los no programadores, disculpad)

El problema a su vez es que es tan flexible que deja mucho margen a las "genialidades" que con mucha probabilidad nadie que no seas tú entienda luego al revisar tu código.

Además como está pensado para programar rápido, para evitar errores javascript necesita que el programador de forma proactiva realize ciertas validaciones que en otros lenguajes como Go Lang son obligatorias de base, pero que también hace un poco más coñazo programar en ellos. Python en mi opinión es un lenguaje con un equilibrio muy bien conseguido en este aspecto.

Así que sencillamente JavaScript mola mucho y es muy ágil pero es más proclive a errores para programadores poco exigentes con su propio código.

Al final el lenguaje ideal depende más bien del tipo de programador que seas y del proyecto para el que lo vayas a usar.

#9 De acuerdo en casi todo. Para mi, el más divertido para el programador es el Ruby. Y con Rails parece pensado adrede para disfrutar programando o leyendo código de terceros. No obstante, es cierto lo último que dices: "el lenguaje ideal depende más bien del tipo de programador que seas y del proyecto para el que lo vayas a usar"

#9 Que va, todo lo contrario.

El javascript cuando empiezas te parece genial precisamente por la libertad que da al programar, ya que incluso a veces programando mal la funciona a la perfección. Pero el problema del javascript principalmente es ese, esa libertad. Ya que hay veces que el código no debería funcionar o dar error donde otros si lo hacen y el javascript no lo hace.

Por no mencionarte de otros puntos flacos del javascript como la dependencia total del navegador para todo (tamaño total de tablas dependiendo del navegador, modo de funcionamiento también dependiendo del navegador o su versión, funcionalidades y limitaciones también dependientes del navegador o su versión, etc...).

De hecho lo que se está imponiendo mucho al programar en javascript es usar frameworks como JQuery o BackBone, porque pone reglas y modos de funcionar al javascript que por si sólo no tiene (además de la utilidad de librerias ya hechas)..

Por todo esto no se aconseja javascript como lenguaje de programación para empezar, ya que no se aprende a programar, sino a salir del paso programando.

#20: Para empezar el mejor es C, porque luego saltar a JS es muy sencillo (y también puedes saltar al Arduino si te gustan los robots). Y aunque programar para consola no sea tan guay como otros lenguajes orientados a interfaces gráficas, es mejor porque no gastas mucho tiempo en aprender un montón de funciones orientadas a interfaces gráficas sino que te centras en lo básico de la entrada y salida. Es cierto que C es muy cabezota con algunos detalles, pero eso ayuda a entender cómo funciona el ordenador por dentro y a hacerte una idea de las limitaciones que tienen.

#46 #9 Ya empezamos diciendo cosas raras, C no está mal (aunque es mejor HollyC ). El mejor lenguaje es Haskell, dejad de mentir sabiendo la verdad.

Y ahora en serio, JS (y los lenguajes más modernos), toman muchas ideas de lenguajes funcionales, muchas de esas ideas vienen de haskell :p.

#97: Eso de "Haskell" suena muy hacker, paso de aprenderlo que lo mismo viene la CyberPolice y me detiene.

A mi C me gusta porque luego te sirve para Arduino y muchas cosas más. Y es más sencillo, no hay que andar con postureos como Java, en C para hacer un Hola mundo basta con:
- Declarar una biblioteca.
- Declarar una función principal.
- En esa función principal introducir una función que muestra el Hola mundo por pantalla.

Y ya está.

#98 Nah, es mucho mas hacker C. Haskell aunque compila a nativo está unos niveles de abstracción por encima de C y de C++ (y Java y Ruby, etc...) . Yo diría que uno de sus puntos más caracteríscos (aparte de ser funcional, claro) es que el tipado es mucho más fuerte que C/C++. Además se integra bastante bien con C :p.

Y por seguir haciendo proselitismo, una de las cosa que sorprenden cuando programas en Haskell es que si compila funciona bien (sin bugs) el 99% de las veces, aunque eso tiene que ver con que no existan variables en el lenguaje.

#101: Si, pero lo interesante sería valorar cómo son de cara a los nuevos usuarios y si luego se salta bien a otros lenguajes.

#97 #46 por Dios hamijos. El mejor lenguaje para aprender es Python. Y lo digo desde la autoridad que me da llevar programando desde los 80

#103: Pues a mi no me gusta porque las secuencias de control del código van con espacios como si de Brainfuck se tratase.

Es mejor poner llaves Y espaciado, sobretodo de cara a los principiantes, que rara vez ponen los espacios siempre de la misma forma.

#104 Python para empezar a aprender es una maravilla, tiene un lenguaje claro, una sintaxis atractiva y además te fuerza a estructurar bastante tu código, y a usar correctamente los márgenes (indentado). Y cualquier identado te puede convertir tabs a espacios y seguir el PEP-8.

#20 Javascript y las páginas web siguen teniendo los mismos problemas que tenían en los 90, empezando por mantener el estado, renderizar continuamente la página cuando cambia cualquier componente y el acceso al DOM. Todos esos frameworks de moda son intentos de atajar esos problemas:
- simular la navegación aunque realmente no salgas de la misma página, y así mantener el estado
- evitar que el refresco de un componente obligue a renderizar toda la página
- estructurar el código y encapsular los componentes

Todos problemas que vienen resueltos de base en cualquier otro lenguaje. Y sólo he nombrado los más gordos.

#9 pues a mí me parece una puta mierda.

#9 La flexibilidad y sus problemas se pueden solucionar con TypeScript y así tienes lo mejor de los dos mundos

#9 opino igual, he visto maravillas en js y mierdas en Go, y viceversa. Al final es el hombre y no el lenguaje (salvando las diferencias).

#6 Puro postureo. Alguien que empieza solo tiene que ver como está el mercado salarial al día de hoy [1]:

Java
Para posiciones de desarrollador con Java, podemos encontrar ofertas desde 20.000€ para un back-end developer, hasta los 50.000€ para un perfil senior o de desarrollo de Android.

Javascript
En el caso de Javascript, el rango salarial va desde los 25.000€ para posiciones de front-end developer, hasta los 70.000€ para un developer senior

[1] https://www.techsalarycalculator.com/

#10 esto sí es postureo.
Si se paga más es porque poca gente domina ese aborto de lenguaje

#10: Esa página mola, porque vas a mirar cuánto te podrían pagar si sabes programar un poquillo el Excel y ni siquiera existe. Me imagino que eso signifique que sólo intereses como becaio.

#10 esos sueldos debes prorratearlos a los 15 días para los que te contratan. Acaso, piensas, que pagarán esa pasta por un año por algo que cualquiera tarda 15 mins en aprender?

#52 ¿Realmente crees que puedes aprender a programar en javascript 15 minutos? Dudo que ni siquiera existan programadores profesionales capaces de ser productivos, 15 minutos después de aprender un nuevo lenguaje.

#10 20k un senior en java?,eso donde? en somalia?aqui esta bastante mejor pagado si en las carnicas empiezas en 18k sin exp...

#83 Vuelve a leerme, ulrok, sobre todo donde digo:

...hasta los 50.000€ para un perfil senior...

#90 si hasta,pero que no he visto en la vida una oferta de senior backend por 20k eso es falso.

#129 Es que decía que un senior es entre 50 y 70k

#6 amén !