Hacker Newsnew | past | comments | ask | show | jobs | submit | castratikron's commentslogin

I may have gotten a dud, but the sensor watch pro board Unused had a _really_ bad crystal oscillator. Like, slow by over 30 seconds a day. There is the oscillator fine tune complication but the oscillator I had was way beyond the max adjustment range (32k ppm). Maybe it was just luck of the draw and I should give it another shot but having a clock that needed to be adjusted every few days was unusable.


this is definitely not normal. I have the non pro version and it loses like 3s per year.


I really like those graphics, does anyone know the tool was used to create them?


The graphs are all matplotlib. The methodology figure is built in Figma! (Source: I'm a paper author :)).


Question to anyone, how does autonomy align with Tesla's goal to accelerate the advent of sustainable transport? How are autonomous vehicles more "sustainable"?


As long as processing one event does not affect any of the other events in the batch. E.g. events are file IO, and processing one event causes another event's descriptor to get closed before that event can be processed.


If the close routine on an event source, or the low-level (e.g. epoll) registration, deregistration, and dequeueing logic doesn't know how to keep polling and liveness state consistent between userspace and the kernel, they've got much bigger problems. This looks like Rust code so I would hope the event stream libraries are, e.g., keeping Rc'd file objects and properly managing reference integrity viz-a-viz kernel state before the application caller ever sees the first dequeued event in a cycle. This is a perennial issue with event loop libraries and buggy application code (in every language). One can't just deal with raw file descriptors, call the close syscall directly, etc, hoping to keep state consistent implicitly. There's an unavoidable tie-in needed between application's wrappers around low-level resources and the event loop in use.


EV charging also uses HomePlug. When Ethernet needed to be added to an existing signal line on the EV connector, HomePlug was chosen as the way to do it. Every EV consequentially will need a HomePlug modem to communicate to a charger, so, the world will have HomePlug around for quite some time.


According to https://en.wikipedia.org/wiki/SAE_J1772, HomePlug is used in Europe. The article is otherwise rather ambiguous about how it's used in common chargers.

At least for the typical level 2 charger, the signaling is an analog square wave.


The typical level 2 charger doesn't have to use HomePlug, but most recent EVs will have a HomePlug modem in order to speak ISO15118 to negotiate the voltage during DC fast charging through the CCS1/2 connector.

The pilot pin that carries the square wave used for J1772 is common to both AC and DC charging, so it's possible for a level 2 charger to incorporate a modem and communicate with the EV.

In many situations it would be an unnecessary expense, but it may become more common even in level 2 chargers in the future since ISO15118 can be used to authenticate the car to the charger for plug-n-charge charging without needing a card or app to authorize the charge.


This is just proportional control. https://en.wikipedia.org/wiki/Proportional_control


Yep. It is also known as exponential smoothing in other contexts.

I wish the author had linked to the wikis for either of those things up front so people who had heard of it already (and know why you probably don't want to use it for your UI) could move on.


You could either 1. itemize the charging bill on their monthly rent, if that parking spot is reserved for one tenant. Really should be no difference from the rest of their electricity use. 2. Charge a flat fee on their rent, and then give them charging for free between off-peak hours. Some utilities offer very cheap off peak rates for EV charging, 3. integrate a credit card reader or bill acceptor for cash payment. Option 3 seems hard if you are trying to cost optimize the charger hardware.

I am bearish on universal PnC being practical to implement. Every EV manufacturer has to make agreements with every EVSE operator to use the same root CAs and same billing system. If you think of an EVSE like a vending machine, there really is no interoperability precedent for this kind of payment. Tesla is special case because they operate both the cars and charging network. But if Pepsi owned and operated all of their vending machines, we probably would have seen the same walled garden.


21.6kbps dial up was pretty terrible


But amazing compared to no connection at all.


Sounds like we need a (inverse) finfluencer index to prevent overexposure to Cramer.


Don't forget the inverse Michael Burry fund to give you black swan protection!


I got one too


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: