I use this to remember what it does and also like thinking of XOR as an operation you can apply with a mask to flip bits (the linked article mentions this).
I don't mind calling the connector an RJ45, but calling this thing an "RJ45 dongle" makes my eye twitch. It's an Ethernet dongle - RJ45 can be used for a lot of other things. For example I've seen "RJ45 dongles" that convert USB to RS232 serial for the console ports on a lot of networking equipment.
I did wired WiFi for CES one year. Made having our iot devices on WiFi on the floor much better than other vendors. It’s a long boring story but it was a fun hack.
I’m actually really interested: I have a piece of stage lighting, that has a 2.4 GHz Wi-Fi controller. I’d love to convert this to wired Wi-Fi. Can you share what is necessary to achieve this hack? Can I “just” run antenna cable between router and controller? Or what kind of radio physics needs to be understood?
Truly wired WiFi is easy with the devices that have threaded SMA connectors for antennas, e.g. the motherboards or the mini-PCs that allow the use of external antennas.
With those you just need coaxial cables of appropriate lengths, also with SMA connectors, for making point-to-point connections.
If you want a network where each device can talk with any other devices, you also need a splitter, also with SMA connectors.
Many WiFi M.2 2230 cards have MMCX coaxial connectors on them, which allow the connection of internal antennas attached somewhere on the case of the laptop or mini-PC.
For these, there are MMCX to SMA adapters, which you can use together with SMA cables.
Some M.2 cards have even smaller U.FL coaxial connectors. For these there are U.FL to SMA adapters.
For devices that do not have any standard antenna connectors, one may need to modify them, to solder some RF connectors, which is hard to do without greatly lowering the quality of the WiFi links, due to additional attenuation and reflections.
I would imagine that the stage lightning microcontroller is running a variant of ESP8266 or something similar where the "antenna" are actually thick traces on a circuit board (https://www.electronicwings.com/storage/PlatformSection/Topi...). This is obviously good enough for regular WiFi, but I would imagine this would complicate an attempt for wired WiFi tenfold.
Unfortunately, I no longer have the opportunity to do this.
Some years ago, I have been working in designing certain kinds of WiFi devices.
For their testing in a laboratory, a wired setup was used, exactly as described, i.e. with SMA coaxial cables replacing the antennas in the units under test, together with splitters and/or directional couplers to implement multi-point networks, and together with attenuators to simulate a greater distance between the units under test.
The majority of the tests concerning hardware and software were done using the wired setup, which allowed the simultaneous testing of a great number of units in a small space, without interference between their different tests. Only a much smaller number of tests was done with antennas, on the units that had already passed all hardware and software tests, so only the behavior of the antennas remained to be checked.
Such tests in wired setups were done both for the production units, for quality control, and for prototypes, where new versions of hardware and/or software were developed, and it made no sense to waste time with wireless testing until the new hardware and/or software was proven to be completely functional in the wired setup.
In a testing laboratory, there would be a huge amount of coaxial cables and adapters, attenuators, splitters and directional couplers, and of WiFi interfaces, so demonstrating a complex setup would be easy. Otherwise, collecting enough devices and accessories to make an impressive demonstration would be costly when you do not actually have a need for those devices.
In a home where you have an Internet router/gateway that has external WiFi antennas and you have a desktop using one of the many motherboards that include a WiFi interface with connectors for external antennas, you could use an SMA coaxial cable between your desktop and the router/gateway, instead of using an Ethernet cable.
This would be the simplest example of wired WiFi. There are cases when this would be a good idea, e.g. when the router/gateway has only few Ethernet ports for local devices and those are already occupied by other computers. In this case buying an SMA cable may be preferable to buying an additional Ethernet switch and also preferable to a wireless connection, if your home has many neighbors who also use WiFi, creating a congestion that slows down the wireless communication.
Anecdote time (but in a more simple case): Like 15 years ago, I got tired of too many wires at home and I bought a wifi pci for my desktop computer. The problem was that the antenna was in the back, so the computer was blockink the signal. I bough a SMA extension to be able to put the antena on top of the computer and it worked like a charm. Best $5 ever.
I’ve replaced battery backed SRAM in several game consoles and other devices with FRAM (Neo Geo CD, Sega Saturn, an HP oscilloscope) and for some it’s drop-in, and in a few you have to bodge some lines.
Won’t that negatively impact the life expectancy of the device? FRAM is rated for trillions of reads and, if the SRAM is frequently read, a trillion reads isn’t that much.
>100 trillion reads per location over 30 years still means you gotta read locations at over 100 kHz 24/7. Not good enough for main memory, sufficient even for frequently accessed configuration values.
Yes. It'd be a problem for running code directly from it - it'd be better to cache it to DRAM so that all reads would come from DRAM and only writes would make it to FE-RAM.
IIRC, it was a common trick with 286 and 386 PCs, because BIOS ROMs were 8-bit wide and shadowing the BIOS in RAM made it much faster.
Holy cow thats cool. So It's like an expensive nonvolatile replacement for volatile memory. I wonder if in the future there could be computers with no sense of "memory vs storage", that it would all just be a single contiguous "memory".
Instead of turning off the computer and hibernating, you just turn off the LCD backlight and the IO.
While implemented virtually rather than physically, two well-known (and very different) examples of systems that unify memory and secondary storage under a single addressing scheme are Multics (1969) and the IBM System/38 (1978).
Note that the present-day IBM i née AS/400 is a direct descendent of the System/38.
I'm not sure what the performance/persistence implications of this (FRAM) actually are...
But to your point, simply copying the processor state to a known location in FRAM (0xFFFFFFF0) and having the start routine read state from that location seem like a very low overhead solution to the problem.
How long would it really take to do something your computer does as part of preemptive multi-tasking? Nanoseconds? Milliseconds? We are talking about $order(hundred) of instructions
This may work on something with the complexity of a microcontroller or SoC, but becomes tricky beyond that. Any peripherals, especially removable ones would still need to be rediscovered and reinitialized on boot. Network connections may have died/reset while the system was off.
Essentially, this scheme has all the major complications of resuming from sleep/hibernation in practice.
I did notice from the article that reading is destructive, so every time you read (or at least every time you read a 0), you have to re-write it out. I wonder how much that affects the practical durability.
Yes, since reads destroy the data, each read causes a write. The chip will handle 100 trillion read/writes. So yes, the chip will wear out rapidly if you do a lot of reads.
I can't really think of a use case where this could plausibly come up. It would take 3 years if you read the same memory location (uncached) 1 million times a second.
There are multiple factors that limit the number of writes that FRAMs can handle: changes in crystal structure as Ti ions replace O, mobile ions collecting at grain boundaries, and something to do with 90º domains.
Reading destroys the stored value; it doesn't necessarily destroy the physical material.
Reading from memory is already destructive in DRAM (capacitor gets discharged), magnetic core memory (need to alter the magnetization state to read out how much energy was needed), and probably other technologies as well.
This is a framework for building things that run on DOS (yes, that means running JavaScript on DOS). If what you’re running DOS on has a working parallel port, DOjS can use it.
If all you want is text chat with no shared history, sure IRC is fine. But think about these features that the chat apps bring:
Search: half-remember some conversation from months/years ago? It's right there, in the app.
Persistent history: onboarding a new employee? All of the company's past communication is there to browse and search (see above point).
Inline file attachments: need to share a small file or a screenshot with someone? Drag it into the app and they can get it at their leisure. No need to mess around with DCC send or uploading to Google Drive and sharing a link, it's right there.
All of these could be solved with IRC (in fact, Slack was initially built around IRC) but they require extra infrastructure and tooling and development to make it seamless, and that takes extra development and hosting costs.
Slack's pretty bad as an information repository. How do you know there hasn't been a subsequent discussion that updated the conclusion of a particular chat? Search isn't particularly consistent in how it serves up results.
By all means chat asynchronously to decide on something, but then get it into a wiki. I actually like Slack's auto-expiry for free accounts, as it incentivizes the mindset - if you want to keep the information around, boil it down into a readable form and put it in the right place in the company's documentation.
Sure, this a correct mindset, and an obvious one for people who build and maintain information repositories professionally, but at an average company with hundreds or thousands of people, it's a losing battle to enforce. Paying for Slack and having the ability to find information in conversations that should have been documented but were not is valuable in practice.
This is the wrong point of view for many (probably most) workplaces, where the officially "maintained" information repositories are often very out of date and where the alternatives are usually: 1) Find a conversation you can at least start from, or 2) Get someone to give you a brain dump now.
Sure, a curated, well-maintained repository could be better. It also requires work time that usually doesn't get budgeted for. Slack is a band-aid, but a useful one.
Being able to say, "I know this issue came up a few months ago, let me see what we decided back then" -- and being able to back that up with a link -- is a superpower. Not everything that comes up in discussions gets documented.
Exactly the opposite of my long-term experience – Slack search is good enough that it’s my first port of call for information, and regularly finds me the right answer. It’s a better information repository in practice than any other system I’ve used at work. That is kind of sad, of course I think “proper” documentation is better, but such is life.
Our group runs The Lounge, and at this point only a couple people use standalone clients any more (and one person with a Matrix bridge). It gives you all the above (except perhaps the company wide persistent history, I'm not sure) and it's still IRC.
>Search: half-remember some conversation from months/years ago? It's right there, in the app.
Persistent history: onboarding a new employee? All of the company's past communication is there to browse and search (see above point).
This is where Slack really squeezes companies. Our (barely) medium sized org has a seven figure Slack bill, and they only support 1 year of history. Going beyond that becomes absurdly expensive. It would be absolutely pricless for me to be able to go back and read older convos. But it's somehow impossible to do without spending millions of dollars. Absolutely insane.
Being able to search in the past for a half-remembered conversation sounds great until you have idiotic, asinine corporate data retention policies that require anything beyond 90 days to be deleted anyway, for some bullshit reason like being open to litigation or whatever and that being subject to discovery.
Then that's implemented with no warning to be able to migrate important info out into a wiki or other documentation. So in the end, no better than IRC really, but I get it, not a Slack problem, but allowing that whiplash at a click of a button doesn't help. Slack seems to help paper over deep cultural problems in a way that makes it all colorful and squishy.
But as other seem to agree, it's pretty bad at keeping anything organized like you want to be as an info repo, there are tools that are geared toward that specifically. Don't crowbar one into the other.
> Being able to search in the past for a half-remembered conversation sounds great until you have idiotic, asinine corporate data retention policies that require anything beyond 90 days to be deleted anyway, for some bullshit reason like being open to litigation or whatever and that being subject to discovery.
> Being able to search in the past for a half-remembered conversation sounds great until you have idiotic, asinine corporate data retention policies that require anything beyond 90 days to be deleted anyway, for some bullshit reason like being open to litigation or whatever and that being subject to discovery.
Well that just doesn't sound legal. In fact, I'm pretty sure Google just got the book thrown at them for this. [1]
That might not be the official reason, in Europe you can argue you sometimes discuss customer info and thus it needs to be deleted once no longer relevant.
Of course stating you're doing it for the purpose of destroying evidence is stupid.
Being able to search in the past for a half-remembered conversation sounds great until you have idiotic, asinine corporate data retention policies that require anything beyond 90 days to be deleted anyway, for some bullshit reason like being open to litigation or whatever and that being subject to discovery.
The company I work for has the same chat retention policy, but despite that, even being able to go back just 90 days has proven very useful!
I don’t know where he got his, but last August there was one on shopgoodwill.com. I was tipped to it on a small retrocomputing Discord server but I stupidly forgot to bid on it. There were only 2 bids and whoever won the auction only paid $26 for it.
It’s interesting to note that the WiFi on the PicoMEM is based on code from yyzkevin originally from his PCMCIA project. And the PicoMEM uses PSRAM code from my PicoGUS project. And then PicoGUS uses Sound Blaster code from yyzkevin. And now I’m getting inspiration from how PicoMEM does address decoding. And so on and so on… This is a pretty cool little open source community we’ve created around the RP2040, cross-pollinating each others’ projects.
