Hacker Newsnew | past | comments | ask | show | jobs | submit | sr-latch's commentslogin

2-3% error is too high, this is something we _should_ be scrutinizing, and healthcare _should_ be more expensive if the reason it's expensive is that we're pouring more resources into it to get diminishing returns on reducing mistakes.

Costly healthcare due to scrutiny is not the problem with healthcare in the US. The problem is drug monopolies, medical (mal)practice without a license by insurance companies, and the lack of taxpayer funded healthcare-as-a-right.

We need to create an environment where someone like Terblanche feels comfortable advocating for himself without feeling like he's being a burden on the ER, and physicians don't feel like they're wasting time by investigating seemingly trivial cases. Such a situation exists because we are not pouring enough money into healthcare in this country.


It feels high to me because most ER cases should be obvious i.e. heart attacks, car accidents and strokes etc. So if say 10% of cases are non standard then 2% overall is 20% off that.


Not only is the case mix much broader than you imagine but even the three things you listed all have plenty of nuance at the individual case level.


We don't have an anti-heart attack pill. Medicine hasn't developed the post-car-accident protocol. Strokes vary so much in type that they can go unrecognized by competent doctors for years.


The ER functions as primary care for a large percentage of the population. They see far far more than the kinds of thing a rational person with health insurance thinks of when they think about medical problems they’d go to the ER for.


https://pmc.ncbi.nlm.nih.gov/articles/PMC10121120/

The study performed by AHRQ used incorrect methodologies and datasets to extrapolate its findings.

The ED is far more accurate with a much lower error rate than the study found.


> 2-3% error is too high, this is something we _should_ be scrutinizing, and healthcare _should_ be more expensive if the reason it's expensive is that we're pouring more resources into it to get diminishing returns on reducing mistakes

There will be rapid diminishing returns. It may cost 5x to get to 1-2%. Maybe 10x.


the way i see it, before these tools, only someone with a lot of resources (or skills) could track down a location from a picture. now, anyone can do it.

the best case outcome is people become more aware of the privacy implications of posting photos online


Does it have internet access? Looks like a very convenient interface for looking for hotels, planning travels


It does, I can certainly add it. I made it because I'm looking to open a new location for a brick and mortar business so I needed a way to look at the competitive landscape, high-level demographics etc...

It would be cool for planning travels! I'll look into it.


This is the project template I use for the RP2040. Removes the hassle of setting up `pico-sdk`, as it just clones it in the `Makefile`.

Easy to add other dependencies such as FreeRTOS, just add it to the Makefile and include it in the CMakeLists.txt

Derived from the work I did at Purdue Space Program (https://sagarpatil.me/projects/cms-avi-sw)


Awesome work! It's really cool to see this from a high school team. While designing liquid rocket avionics [1] at Purdue Space Program, we went with a BotBlox switch that cost $80 apiece [2], which I thought was ridiculous. My proposal to in-house the Ethernet switch was vetoed because I was a filthy CS student (joke) and my co-lead (the electronics guy) said it wasn't worth our time designing and validating such a part.

An Ethernet switch for $6.9 directly from JLCPCB is pretty incredible, thank you for making this product sector a tiny bit better :)

[1] https://sagarpatil.me/projects/cms-avi-hw

[2] https://botblox.io/products/micro-gigabit-ethernet-switch


I think you should submit your project page [1] as another show HN, I found it to be interesting

Some thoughts:

- Agreed with not using I2C, I2C has been identified as a root cause in several cubesat mission failures: https://pure.tudelft.nl/ws/portalfiles/portal/10531886/art_3... and https://webapps.unsworks.library.unsw.edu.au/fapi/datastream... (yes clock stretching is evil). I2C should be banned for multi board communication

- Classic CAN have very small 8 byte MTU with frame preemption, which is actually useful for its intended purpose of time critical automotive data transfer. If that 4 byte brake packet is blocked by a 1500 byte packet then your car will crash and explode. But the tradeoff is that this makes it very slow for bulk data transfer


Wtf, I2C in a satellite!? I am by no means an electrical engineer or know anything about doing stuff in space but it seems absolutely obvious to me if you require any sort of communication, that you use differential signaling. Even on earth you can have interference, in space with all its radiation it's guaranteed. I'm surprised anything worked at all with I2C.


Yes, I2C is technically meant for intra-board use. But it works surprisingly well over large distances if you avoid daisy chaining and run one cable to each target. If you use multiple identical target chips you need to route everything individually to a central MUX anyways.

As an example, the Nintendo Switch used I2C over a ~2m cable to communicate between the controller and nunchuck. Worked fine even in noisy household settings with wifi and microwaves and whatnot.

At work we've used sensors for data logging that communicate using I2C over distances more than 20 meters, using plain Cat5 cable.


Do you mean the Wii?


Yes, of course I meant the Wii, sorry about the mix up. Too late to edit now.


Thanks for this! I recently designed a sensor board that connects to our main board with I2C, and in chatting with an EE about it she mentioned I2C is not intended for intra-board use. I just put a scope on the signals yesterday and they seem okay. The cable is only 15cm long, and it connects to a multi-use port which would be difficult to make work with differential signals in addition to the other things that port can do. I’ll keep an eye on it but maybe it’s okay.


I2C doesn't really care about cable length all that much. The thing to keep in mind is the interplay between bus capacitance, pullup strength, and drive strength.

A longer cable means more bus capacitance, which means with the same pullup resistor the signal rise time will be higher, which means you need to reduce the bus speed. A stronger pullup will reduce the rise time (allowing a higher bus speed), but each chip's driver has to be able to overpower the pullup too. If the pullup is too strong for the drivers, you end up being unable to send a zero.

In practice your cables can be quite long, you just have to run it at a lower speed. If you really want to push it, there's always transceivers like the PCA9615 which turn it into a differential bus.


If you _must_ use I2C, then look at SMBUS if its an option for the parts. I2C's biggest failing is that there is no protocol level timeout, so one stuck device can block your entire bus unless you have a reset line for all the peripherals on it. https://www.analog.com/en/resources/design-notes/guide-to-co...


Classic I2C problem. After your CPU resets, at least clock out a bunch of cycles onto I2C to get interrupted I2C transactions to finish.


Ooh this is great to know thank you!


Not an EE here, but I've dragged some circuits together as a hobby and have only used I2C. Why would Nintendo opt for I2C instead of a differential pair? Is there some extra part cost? What part(s) would you use to go from I2C to differential?


I don't know why Nintendo did it. But it's certainly quite convenient, there are even standard form factor breakouts for the Nunchuck like in the link below. This gets you a controller with accelerometer, 2 buttons and a 2 axis joystick with plenty of libraries available for using it with Arduino, RPi etc.

https://learn.adafruit.com/adafruit-wii-nunchuck-breakout-ad...


I don't know about I2C specifically, but a related device is a serdes (serial-deseria) which converts between a parallel interface and one or more differential pairs.

https://www.latticesemi.com/what-is-serdes

Someone else mentioned the PCA9615 which looks like it'd to the job.


You usually don't find I2C in the high end space-rated parts simply due to the added complexity of a simplex protocol but you see tons of single-ended SPI parts. You don't need diff pairs unless it's for high speed or long cable runs. If your controller (FPGA, microcontroller, etc) has the resources, a good idea is to have a single SPI slave per master. Also since SPI is not standardized, vendors may have different signaling requirements which makes it slightly more difficult to put different chips on the same bus. Talking to SPI chips is super easy and can be implemented entirely in 7400-series logic if you want so it's entirely possible to have analog electronics send control signals to SPI devices without a single CPU in sight.


"making this product sector a tiny bit better" is exactly what MUREX is all about :). It's something we honestly believe in and will continue working on as long as we're around. Believe it or not, the Ethernet Switch was the least problematic piece of hardware in our tech stack! If you want to take a look, we have our other boards in the docs as well. Your rocket is so f*ing cool as well! I definitely want to do something similar in college.


Ok this is sick, I love the philosophy of your team. I'll be strongly considering your CM4 carrier and ESC to integrate into future designs.

Also thank you, I've loved working on the PSP rocket! Bi-propellant rocketry is a pretty rare to do as an undergraduate, and you should consider applying to these schools if that's something that motivates you:

- Purdue: https://purdueseds.space/

- Berkeley: https://www.berkeleyse.org/

- UCLA: https://www.rocketproject.seas.ucla.edu/

- Georgia Tech: https://www.gtspaceprogram.com/

- ERAU: https://daytonabeach.erau.edu/about/labs/rocket-laboratory

This is a non-exhaustive list of schools I know that have undergraduate-run liquid rocketry programs.


and Portland State University!

https://www.pdx.edu/psu-space#psas

Undergrads, not catching on fire in space!



Thanks everyone! Noted deeply in the heart. :)


Congratulations MUREX Robotics team, great job!

There are products at different price points on the market, for example this 55x55mm switch from my company Brainboxes[1] is sub $50. We choose that size so that we could also produce a gigabit option with the exact same footprint. We opted for microMatch[2] style connectors as you can get board to board as well as board to cable options.

Your co-leads decision to buy-in is quite common, as you can reduce time to market and also not have to manage the component lifecycle if you go with an off the shelf option.

[1] https://www.brainboxes.com/product/pure-embedded/pe-505

[2] https://www.te.com/en/products/brands/micro-match.html?tab=p...


That's a sick board! If we had found that before we made it, maybe would have just used this board haha. What is "buy-in"? Is it meaning us using JLCPCB to buy and assemble the chips?


Thanks! Like yourselves we saw a clear niche for a ultra-reliable small embedded board suitable for robotics and other space constrained systems. I'd be very happy to send you one of our products to compare, i'll message your team email.

By "buy-in" I was referring to the parent comment and how the electronics guy chose to buy-in a pre-made module rather than design their own.


Worth noting though that the switch you linked claims to be a gigabit switch while the switch from murex is 100Mbpbs.

Not sure if that justified the price difference


If you've taken a compilers course, it's pretty similar to register allocation. You want to make sure you're using as much of the processor as possible.


This is absolutely not true - injector design is the most important aspect of designing a thrust chamber. Poor mixing of propellants leads to severe combustion instability, which often leads to explosions. Even the earliest space programs did significant testing on propellant choices and injector designs (see Ignition! by John D. Clark)

Also, pressure fed rockets have always been a fairly terrible design. Pressure feeding requires heavy tanks, and incurs a big mass fraction (dry mass / wet mass) penalty. Outside of rare cases, it's only used for ground testing.


just drop the tank when the weight/thrust ratio is too low. Thanks for the book suggestion! (have not read it yet)


The rocket equation would like to have a word with you. The wall thicknesses required to create rockets with enough thrust to get to orbit on pressure-fed would render the rocket physically impossible.

There is also a lot of control that goes into flying a rocket, and pressure-fed rockets are kind of hard to control.



Is this the codebase that they took down ???! Yes to all of the things you can do (minus the passive radar stuff beyond educational purposes that is ;)

edit: looks like they took down all the passive radar doppler videos : https://othernet.is/products/kerberossdr-4x-coherent-rtlsdr


and if you're ever writing 1DoF codes yourself, NASA's CEA for propellant chemistry calculations is freely available https://cearun.grc.nasa.gov/


The executables and source code are sadly not freely available any more, allegedly for ITAR reasons.


Clickbait headline


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

Search: