schobi

This is really awesome!

I was surprised about using dilation. I would have expected music21 to support rendering to a certain resolution/dpi setting directly and avoid rescaling the images. But from the music21 documentation this is not obvious how to do it. Rendering music to a low dpi screen nicely (pixel perfect) could circumvent some of the hardware limitations in the mid term.

I love the out-of-box thinking and clean execution by mitxela. But why not make it the other way round?

Downsides: you need enough magnetic knobs and store them when not in use. If this becomes popular, will all knobs be compatible? What if you loose some? If you buy a used module? This idea somehow creates a new set of problems.

Idea: Knob with a plug!

The outer dimension of a knob is limited by how easily you can grab it. Even if used as a socket, you need the sideways spacing anyway. But the knob face is not used. Why not have the socket in the center of the knob?

How to build this? You would need a hollow knob riding on a bearing surface around the socket. I vaguely remember magnetic position decoders that work off-axis? Or maybe have multiple magnets in the rim of the knob, in an orientation that creates a uniform magnetic field in the center? The current prototype would even be suitable for trying.

Benefits: no extra removable components. Knob and socket can be used at the same time. Can you still reach around a plugged-in cable? Is this even useful?

Right - unlikely this is going to work.

For sending a VGA signal even at 640x480 you will need a short h sync pulse of 3.8us at 31.x kHz. You would need an audio interface without filters with single low pulses at 260 kHz samplerate. Otherwise the monitor will just not detect a signal.

You could however use h sync and v sync from the VGA output and feed audio to the rgb channels. But thiswould give a mess of wires and is far from the beautiful idea shown here to just connect the white/yellow plugs differently.

There is certainly also a device limitation. I would expect that with less than full 24 bits of color, some fields might just look the same and the results do not depend on your vision any more.

Let's say the device has a "24 bit color display". What about eye protection color shifting? This limits the color space used could reduce the effective remaining bit depth. Or maybe they do temporal dithering to get more bit depth? Or maybe the 24 bits are already achieved with temporal dithering?

It does not need to be a calibrated display, but a cheap tablet in sunlight will be worse than a color grading monitor in a reference environment.

I hope they also register the devices used and analyze the statistics on that.

When building a camera, you decide once and then most parameters stay fixed. It would be trivial to just append 1000 bytes for a mostly fixed DNG header to each image.

But how do you test this? While the DNG specification is open source, the implementation was/is(?) not. Do I really need a copy of Photoshop to test if my files are good? How would I find good headers to put into my files? what values are even used in processing?

Maybe the situation has changed, but in the old days when I was building cameras there was only a closed-source Adobe library for working with DNGs. That scared me off.

Nitpicking correction: The sensors give you a fixed number of bytes per pixel, like 10 or 12 bits per pixel. This are unsigned integers, not floats.

Typically you want to pack them to avoid storing 30% of zeros. So often the bytes need unscrambling.

Any sometimes there is a dark offset: In a really dark area of an image, random noise around zero can also go negative a little. You don't want to clip that off, and you don't want to use signed integers. So there typically is a small offset.

This is an interesting idea, but I'm sceptical of the advantages.

"there is more Co2" is valid for cars burning fuel. But as soon as you recuperate (even in a hybrid) you might only have a fraction of the losses any more. Adjusting the speed more aggressively is possible, without breaking, with little loss. I totally agree that stop-and-go is annoying, but looking into the future, Co2 should not be a reason for the vehicles in 5-10 years when the research can be rolled out.

Is "slamming the brakes" still happening? Around here you have dynamic speed limit signs on the highway. In high traffic everybody then goes a little slower, but smoothly.

I suspect that if a road is loaded beyond max throughput, this method will also fail, even harder. Let me explain: I remember a graph from communications theory. With improving error correcting codes in transmission, you can get a clean signal for even worse channel conditions. But once it fails you will not have a signal any more. The better the code, the steeper the cutoff. Whereas without in FM radio, the degrade in user experience is also gradual.

So the analogy goes like this: I would expect that you could possibly load the road with another 10% more vehicles. But if one day you have 15% more, the blockage will be even worse than before. Could be worth simulating throughput for various loading situations.

Seems like a spark or sparkline describes a bar graph, rendered inline in regular text. There is some font magic to render {30,60} as small bars in the text.

Nice, but the terms were new to me. Would have helped to explain them first.

Wouldn't it be great if a universal standard existed for devices sending their diagnosis via audio?

If there is a microcontroller and a beeper in there anyway, at only the extra cost of internal memory? Instead of a modem-type modulation and a speaker, make use of the bare minimum piezo beepers and send something that is universally understood? All of that without FCC, no extra hardware cost, no backchannel und thus little security considerations?

Yea - I know. Works much better to upsell "wifi enabled" and I'm happy that the appliances only beep rarely.

They tried on the moon, but there does not seem to be an assumption that this is limited to the moon? So one could obtain a position anywhere in earth's orbit, up to heights of 380.000km? 1.5km accuracy is impressive then.

Apart from the attenuation from distance, I would expect that the navigation sallellites point their antennas mostly downwards to earth, but you might find some that radiate outwards. I don't think you can expect to receive from half the satellites though.

Similarly, the dfplayer mini is fine if you want some sound to scream back at you. Works on button press, but also rx/TX for track management from micro SD card. Small amplifier built in.

I built motion activated playback speakers - good for hiding them in the bushes on halloween.

Best overall is just a start. Typically I have more specific needs, depending who is joining, what I had this week already. Now that you have the data, you could ask an LLM to rate each restaurant (from comments and website and menu) to find a specific recommendation:

I need a place for business lunch for 2, should be a quiet place, not pizza.

Recommend a good place for a dinner for five, should have vegetarian option. No burgers, we had that last time. We plan on sitting and chatting longer, not just food.

I understand that historically it was 16 2/3 Hz and power transfer from to the 50 Hz grid was done via 1:3 mechanical coupling with a motor and generator. That was a ratio easily achievable with gears.

Nowadays with switched power supplies, this is not a problem any more. Keeping track of 16.7 Hz seems a little easier. Imagine building a numeric display for a power plant operator to see how far off you are.

I've built a KNX house about 10 years ago and I'm still quite happy. Let me share some experience:

Having the light switch on the smartphone does not make it any smarter, just more complex.

The following automations are the most valuable for me:

- automatic blinds. Go down when too much sun hits the facade, go down when dark outside, go up with too much wind. No concern leaving for work, and coming back to an overheated living room (no AC needed). But still automatically collect the direct sun in winter/spring.

- motion sensors, turn on lights when dark and motion in the room, every room

- night mode - low level motion-activated light in all bedrooms, corridor and bathroom. No automatic lights in bedroom, orientation lights on, night light sockets on, blinds down

This brought me to rarely touching a button/switch, twice a day, maybe?

And then there is toys

- blinds can fully close when room is empty, but go to half tilted with presence, angles following the sun, for maximum natural light without direct sun

- TV lowers the blinds behind that would give a reflection

- opening the terrace door opens the blinds and turns off indoor lights, to not attract mosquitos (idk if that even helps)

- shower motion sensor turns ventilation on high

- some sockets go on/off for Christmas lights

- logging of appliances, water, ventilation, heating.

I like that the low level stuff in KNX does not need/have a central hub. But the higher level requires extra smarts. I plan to migrate those to Home Assistant this year.

I'm glad they only thought about it, but did not implement SF6 flooding of the chamber. No need to vent it to the atmosphere just for fun.

But controlling the internal pressure? I would expect that only a small difference would be needed - far from exploding or imploding the clock! Maybe small enough to have a reservoir and control only inlet and outlet valves? This could be done purely without modifications of the mechanism.

What I understand from the presentation

Many Volkswagen cars somehow report telemetry. Looks like there is data not only from the EVs based on the MEB plattform? But for a Name/email to be associated with the VIN of the car, the owner has to register and use the app (once). Many EV owners did, but fewer of the non EVs did.

The article says "at the start of the join operation the bits will be set in the bloom filter".

So maybe this is built for every query? Would be needed anyway if there is a where clause for the joined table.

I recently learned about an activity at CERN. They try to transport antiprotons to a different site for better analysis. "BASE STEP" https://home.cern/news/news/experiments/base-experiment-take...

Surprisingly, antimatter can be stored for months. They built a 2.5 ton storage box, ultra high vacuum and magnetic trap and a loading mechanism. In a first trial they loaded 70 protons and drove around the campus on a truck.

Impressive that this is even possible. But with 2.56 * 10^-15 Wh/kg still orders of magnitude from current batteries.

Great idea and writeup!

One important feature is missing: From a proper search function I would expect to know how often my string is found. It could be that my password is rare, or that it is rather common. I need to know! Could the search also display the number of hits?

Jokes aside - you know the number of digits of the search string and if it is still a valid uuid. So computing the number of "matches found" should be possible...

I could imagine some candidates starting with their default tools like this, and start complaining about the cluster performance after a few weeks.

You need a certain way of thinking to have a gut feeling "this could be expensive" and then go back, question your assumptions and confirm your requirements. Not everyone does that - better to rule them out.

Wow - that rental situation sounds painful. Almost like malicious compliance to discourage EV usage.

Around 2019 I rented an EV from a retired enthusiast, and this included all bells and whistles, charging cards and cables. Pricey back then, but great experience. This is how you convince people

Most people miss, that you do not need a full and fast charging infrastructure at home. I rarely need to fill the car from empty. I rarely need to jump on the next multi hour trip right away.

If you "stay with family" I assume this is a few hours or overnight. Even slow charging from a regular outlet gives enough over night or a 6 hour stay. In Europe a regular outlet can give 3-4kW, so 6 hours is enough to go another 100km.

At work they installed a lot of 11kW chargers. Sure - some might need them, but most people would be fine with topping up their cars every day on a single phase charger. You park there for 6-8 hours, even at 3-4kW that would be enough for a daily 200km commute (which is rare, that guy can go to the 11kW charger).

I stayed in rural Italy with really old crappy electricity. Even there I could hookup the car on single phase at 1kW and keep charging. Two days later it was full again.

I really like the aestectics, even if physically wrong at the edges. Thanks for sharing the details.

As a embedded developer, I feel this is kind of wasteful. Every client computes an "expensive" blur filter, over an over again? Just for blending to a blurred version of the background image?

I know - this is using the GPU, this is optimized. In the end, this should not be much. (is it really?)

<rant> I feel the general trend with current web development is too much bloat. Simple sites take 5 seconds to load? Heavy lifting on the client? </rant>... but not the authors fault

I love that he openly discusses the paths he went wrong and how more accuracy could be found. Detection threshold from the sensor or avoiding accidental synchronization to the monitor are not obvious pitfalls. The mini ASCII histogram is something I need myself - nice thought!

I remain puzzled on the goal. Does he optimize his setup for a good coding experience? (this should definitely include the actual keyboard in the measurements!) Is he optimizing editors? Picking a new monitor? As a learning excercise?

I'm all for "because I can" as a valid reason, but that often leaves my projects dangling halfway complete. Are we there yet? Don't know - not sure where I want to be.

You would be doing "lucky imaging" to get around atmospheric disturbances. Basically, you take 100 images with <100msec exposure times. You check which ones were good, and discard 95 of them. Then you overlay the good ones. That would explain the high number of images taken.

I can imagine situations where I hold something, thinking "this needs to go there". Cleanup, but also moving days, gardening, construction. I like the concept of the "luggage from sapient pearwood" - maybe tell it where to go, drop off something and come back? Put a box on it, and it will carry it down the stairs?

This is not it. Needs to be quiet and energy efficient, but still handle stairs and garden... If I need to follow it, I could just use an exoskeleton - no, please make this autonomous.

If you've solved voice interface, navigation, low power.. Then you almost have a humanoid robot who could also put the laundry in the washing machine, not just next to it.

A camera+lens set up to 5 micron/pixel will have a shallow depth of field.

I looked up some numbers: The pixels of the camera are 4.6um, so the likely used a 1:1 makro lens (likely the HC 4/120mm). You will capture a 53x40mm region at once. The working distance for this lens goes down to 40cm for 1:1 magnification (might have been 40-45cm). Aperture 4 (as little diffraction as possible)

If we put that in a calculator, depth of field is only 240um. This is the working range where the object needs to be to be in focus.

I'm surprised the painting is that flat over a single image. Even a high spot on the canvas or an extra dab of paint will be higher. Maybe they took multiple images and focus stacked them?

Right. Fpgas shine if you have high data rates (multi Gigabit on single/dual pins), low latency, lots of similar computation (multiply accumulate), a lot of complex pipelined logic and if you need to be really compact at the same time.

The effort to get this running is also crazy huge. Large designs "compile" for hours, simulation and in situ testing can take months. If your fpga has 1000 pins, even PCB design, manufacturing and debugging is hard, if you even have a sufficient scope at hand. I would guess 10x compared to solving a problem with an embedded cpu, which is 10x compared to solving a problem on a standard PC. Expect another 10x if you go from Fpga to custom ASICs.

I'm curious what could be expected / possible with 5-10k. Tweaking an existing design, on proven and available hardware? Testbench for a module only? Maybe "just" VHDL/verilog coding (instead of dealing with the Fpga)?

(sorry, no marketplace)

Same understanding: On the receiver side, we are going to drop duplicates (by processing, or by having no effect on the grass cutting any more). Thus, the end user is then seeing only one effect, one message delivered. The effect of delivery "message received" or "grass is cut" is achieved.

But still, the sender might need to send more than once (until confirmation). From the cost at the sender "sending multiple packages" or "sending more grass cutters" this is still the scenario "send one or more".

Sorry to fuel the fire... it is about the definition of "delivery"

I would love to see some footage off that in a throw - I would expect a blurry mess.

With panono, they captured a single shot at the highest point in a throw. In daylight, short exposure time. Only when throwing straight up without strong rotation.

With (uncooled) microbolometers you can't have a short exposure times and might end up with 20-30msec effective exposure. This thing might be harder to throw up straight without rotation. Throwing through a windows or rolling? Please show me that this does not give a blurry mess, but gives useful images! Demo footage suspiciously missing...

Edit: I stand corrected - the spot video does not contain thermal but shows NIR images. One can see some point projections from a depth sensor?