byb

I've had the same desire to extend USB HID devices, but I want to take it a step further. Once a USB device <- Wi-Fi ->USB host technology is available, then a wireless USB switch should be possible. The research in this article is critical to understanding the impact of latency on the experience.

Several months ago, I built a project using USB host mode on a Raspberry Pi Pico, which uses a USB numpad to pass messages to an MQTT server. This uses the Rp2040's USB host mode https://gitlab.com/baiyibai/pico-w-usb-host-mqtt-numpad

https://github.com/adafruit/Adafruit_TinyUSB_Arduino

My implementation plugs in much higher into the stack and doesn't read the full USB bit mask output, which indicates how many keys are pressed/released.

From my limited understand ing, it should be possible to pass these USB messages from HID client to HID host and vice-versa. Then it's only a matter of sending this information over a TCP/UDP interface. However, from my research, it seems the TinyUSB library doesn't provide the full bitmask resolution necessary for all devices. The YouTuber Wendell from LevelOneTechs has also talked about the troubles of getting some devices working with his KVM products, so it may not be as simple as I'm suggesting here.

Overall though, a $15/endpoint is very attractive.

I tried using a Flipper with some NFC stickers so I wouldn't have to carry around so many FOBs and cards. It turns out that the Flipper does not excel at this task. It complained that the NFC stickers I bought were non-writable. And it couldn't read all the sectors on some NFC tags. However, I was able to use the Android MCT app to write to the same stickers and read the tags the flipper couldn't read. Cloning required copying strings to the clipboard, which is something the Flipper's UI is not really designed for.

This is the point of mechanical/electrical interlocks to prevent exposure to energized UVC. This is why I find the attempt to make 'far uv' safe in the public conscious even more dangerous.

Personally I feel the use of the term "far uv" is very misleading because the 220 nm wavelength is within UVC, and not too far away from 254 nm germicidal UVC. It is always helpful to consult a chart:

http://www.drb-mattech.co.uk/uv%20spectrum.html

So, from a public health/public education standpoint, I find it troubling that scientific research, which the article points out, is limited in this area. For decades, general advice has been that all UVC is dangerous to all life. We don't know below which wavelength does UVC no longer become harmful to animal (human) cells. Nor do we know if 220 nm wavelength light damage/weaken other materials. I'm not a chemist/engineer so I don't know if theoretical calculations can be made or if a massive scientific effort needs to be done to verify the impact of 220 nm UV light on lots of materials/life.

If there is an animal/human cell safety region, perhaps a rebranding or subdivision of UVC into a "UV-D" is better than calling this "far uv". This has the added benefit of the "D" meaning "Death to germs/viruses".

YouTuber Big Clive has had several videos on UVC lamps, I'd like to see someone get a 220 nm light into his hands to see if he smells like burnt meat. https://youtube.com/watch?v=1m0TQjBRcFo https://youtu.be/6DlfLthx89E?si=V4FD0DO4l09w2Wlr

Edit: maybe I am a bit alarmist, some comments did share additional information about products offering this technology... I still hold that the branding/messaging is a problem by lumping it all together

In most cases no, AsciiDoctor-PDF converter uses the Ruby library PDF library Prawn to generate PDFs, However, there are alternative PDF converters which do convert from HTML (the VSC AsciiDoctor plug-in allows the option to use a different converter), but I don't think they use chrome. Please note that using different pdf converters is a bit of an advanced topic. https://wkhtmltopdf.org/, and asciidoctor-web-pdf. https://github.com/ggrossetie/asciidoctor-web-pdf

I encourage everyone to take a look at the documentation; this is the markup language I now use for all my personal and professional projects. https://docs.asciidoctor.org/

I want to second your comment. AsciiDoc is growing in popularity. A year ago I surveyed a dozen tools and went all in with it.

I'd like to see IJ take it a step further beyond AsciiDoc, by supporting Antora to generate and deploy static websites. When combined with Antora-Assembler its also possible to generate PDFs using the ruby-based AsciiDoctor PDF.

I'm currently introducing a Docs-as-Code workflow using Visual Studio Code at my organization, because of the very permissive license terms of VSC and the decent AsciiDoc preview function. Mostly though, I find reading adoc files quite easy until lots of Antora snippets (which don't resolve) and conditions start getting added in. A lot of technical writers I've met have had a hard time understanding XML, which is nothing to say of the average office worker who wants to open up their old copy of Office 97 and write a completely unstructed document with a WYSIWIG interface.

IJ IDE licenses start to add up, so if IJ is competitive against Oxygen, this might make sense for a lot of organizations to jump over.

Neat project. I'd really like to author plain AsciiDoc on an e-paper display without distractions.

On one of your earlier commits (https://github.com/rberenguel/PiWrite/commit/c23bfdccd43e1c5...), you mentioned using a Pico W. There may be an avenue for that. A few days ago I submitted my Raspberry Pi Pico W Host MQTT Numpad project to Hacker News, but unfortunately it didn't gain any traction. https://gitlab.com/baiyibai/pico-w-usb-host-mqtt-numpad. I detail some of the developments on USB Host mode. There doesn't seem to be native MicroPython support for USB Host mode yet. I did find a project which seems to to load the pico-pio-sdk as a library and use a GamePad for input: https://github.com/danjperron/pico4legsBot

Also, about a year, I wrote down some of the requirements for an e-paper RPI Pico-based e-ink writer in a comment. I wanted to dub mine, 'the microWrite', 'μWrite', 'uWrite', or 'you write' https://news.ycombinator.com/item?id=32092930.

I suppose the question is whether it is feasible to adapt PiWrite to run in MicroPython. The next question is whether one could ditch the webserver-based approach and interface an e-paper screen directly to the RP2040. Waveshare offers MicroPython libraries for their e-paper displays. This might offer better latency.

The Pico W USB Host MQTT Numpad is a proof of concept for the Raspberry Pi Pico W. It demonstrates USB-Host support for a USB numpad which connects via Wi-Fi to an MQTT server. This allows integration with smart home automation software such as Home Assistant to control smart devices.

I have been thinking about building an open-source RPI Pico-based E-Ink writer for a long time. I was primarily motivated by my opinion that the Freewrite seems way more expensive than its components should cost. I also didn't like the industrial/mechanical design, and I didn't like a lot of the choices made by the company (cloud storage). I wanted a little more flexibility, such as being able to use my own keyboard. I haven't started a GitHub project page and unfortunately, I don't think I have the capability of pulling this off as a single hardware/firmware developer, so I'm putting my ideas into the ether so that maybe someone picks this up and brings it into a reality.

The webcomic "The Guy I Almost Was" put me down this path twenty plus years ago. There's a part of the story where the author daydreams about buying a typewriter at a garage sale - the same one William Gibson used to write Neuromancer - to pursue his own fantasy of becoming a beatnik novelist after nearly becoming broke, homeless, and rejected for not having the latest Apple Newton. https://www.electricsheepcomix.com/almostguy/ Writing and editing became a large part of my career in technology, but I've felt I never developed the habits of a 'good' writer and am distracted like everyone else by the Internet at my desk and my cellphone everywhere else. Several writers have talked about using old word processors to write their novels and I thought I could be one of these people. Back in 2016 my iPhone 5 screen was damaged and I didn't have the funds to fix it, so I ended up buying a Chang Jiang長江 card phone which could fit in my wallet. It was bliss, until I began 'missing out' on the social scene happening in group chats... but I still yearn for an offline, disconnected experience and continue to pursue this idea.

I call my e-ink writer 'the microWrite', 'μWrite', 'uWrite', or 'you write'. I call it this since I'd like to use micropython as the basis of the firmware/software. An e-writer was one of the first projects that came to mind when I discovered micropython. I don't think lack of USB host mode is the biggest problem; this can be overcome with an extra micro-controller. There are several options which I'll detail in this post. The major components of the MicroWrite can probably be had for less than $150, and perhaps half of this at scale and if a smaller e-ink display is used:

- An RPI Pico as the main processor module.

-- The new "w" Wi-Fi enabled version takes care of connectivity.

-- The castellated pads makes integrating the RPI Pico onto another PCB very simple.

-- The 'sleep' function of a microcontroller combined with an E-Ink displays persistent image retention when powered off seem like a perfect combination.

- An e-ink display. There are many more options on the market nowadays.

-- Pervasive Displays has a large number of options with different sizes, resolutions, and features, such as partial refresh (they even have micropython libraries for some of their product line): https://www.pervasivedisplays.com/

-- As a stop-gap solution, I thought about finding a large character LCD or VFD to test out the basic hardware concepts before diving into e-ink.

- USB host IC. Since the RPI Pico doesn't offer USB host/OTG functionality, a second controller co-processor/micro-controller allowing users to plug in their keyboard of choice. However, YouTuber Ben Eater has made a few videos explaining the complexity of USB keyboard protocols (basic/advanced), so supporting every USB keyboard could be a challenge. Luckily there is a WCH CH559-based project which allows USB to serial translation. The RPI2040 has 4 serial interfaces which could handle this input.

-- https://github.com/atc1441/CH559sdccUSBHost

-- Another option is the Maxim MAX3421E (I bought a dev board for this and never opened it) https://www.maximintegrated.com/en/products/interface/contro...

-- There are more discussions about USB host on the micropython forum: https://forum.micropython.org/viewtopic.php?t=6013

-- It might also be possible to use a WCH376, these are popular ways to add USB flash/SD card storage to 8-bit systems (ISA), but peripheral support hasn't emerged from the open source community.

-- Another option might be bluetooth, but I didn't investigate this that much.

- Power. This is a bit more complicated since various buck/boost converters, and battery charger ICs would be needed to supply the various voltages, handle charging, powering a keyboard, and handling "sleep". There are so many options, such as 18650 lithium or larger cells, or Nokia batteries, that this isn't a major concern.

- Storage and connectivity. There are also a lot of options for this. Millions of characters can be stored cheaply and the RPI Pico has a lot of great connectivity. I didn't like the cloud features of the Freewrite, but I suppose those could be implemented easily.

- Industrial design. 3d printing is ubiquitous and I'm sure a community of designers would design their own bespoke options to accommodate different screen sizes and layouts.

- Manufacturing. There are so many PCB manufacturing houses available now. Kicad has put schematic and layout tools into the hands of anyone willing to learn.

Software Design Considerations

There are so many software design considerations that the project becomes overwhelming.

-How many characters are "enough" to show on screen?

-Do I incorporate different font sizes?

-Do I use monospace fonts, or try to implement proportional fonts?

-Do I stick with an ASCII character-set and ASCII file-encoding, with a simple 80 column screen or do I go all out and try to implement unicode right-to-left language support for languages like Hebrew and Arabic and IME input for East Asian languages?

-How do I handle screen updates and 'keeping track' of what parts of the e-ink display need to be updated? My biggest concern from a software perspective is actually the biggest grip from the author: How would I implement the cursor/editing system and screen update routines? I came across this page which opened up a can of worms: https://lord.io/text-editing-hates-you-too/

-How do I handle the 'sleep' routines for the USB host IC, E-Ink, and the RPI2040 to conserve battery, while at the same time remaining responsive enough to the user (so that keystrokes are not lost).

Future

If all this could be solved, the microWrite could be used as a terminal device; allowing SSHing into another computer. Or maybe it could even be used to expose the python repl environment, allowing individuals to code from it. It could also be the basis of an e-reader; and maybe this is a first step to solving the challenges of displaying text.

It may vary well work best by genre, or not cater to people who have gone through spaghettification (insist on subdividing genres infinitely) with their music.

For example, take the "Phonk" genre, which I only was introduced to due to the Ukrainian war. To mean these recommendations give me a lot of new music to listen to. But then you have people lamenting that "Phonk" has really been overtaken by "Drift Phonk". https://www.youtube.com/watch?v=UAV7hnCB_ZE&ab_channel=yokai

On the other hand, I personally enjoy albums and songs major artist after they achieve critical success, when they establish their signature sound, like David Bowie(1970-1983), Stevie Wonder (1972-1976), or Peter Gabriel(1986-1992), but if I "like" any of these songs on Spotify, it means I get their entire catalog mixed in my daily mixes, and if they ever release a live album, those tracks show up. This is not what I want.