Akima

I have like 120 of the 3Bs sitting in our R&D shelf... might not be what's you want but could get you running until you can get your hands on a 4B. I'm in the UK so shouldn't be difficult to ship you one over.

I already import stuff from Protocase. My question really is if anyone is aware of any UK companies that operate in a similar fashion. It's easy enough to find companies that do individual elements of what Protocase do, but I'm yet to find a company that does all.

Is anyone aware of a UK equivalent of Protocase? No MOQ chassis production with powder coating and silk screening. Its easy enough to find vendors that do each of the above separately, but in yet to find someone who does all three. At least in the UK. Don't get me wrong. I use Protocase a lot and have ZERO concern about their quality and capability. However, just looking at my UK options. I know they ship to the UK.

There is valid argument to suggest that a lot of legacy hardware is still available on the Intel Embedded Roadmap. In the industrial sector, you have the likes of AAEON, Advantech, Axiomtek, etc, that build devices with a 15-20 year availability. There's still plenty of these IPC manufacturers that have boards/system with 1st generation Intel Atom CPUs, even AMD Geode! There is a huge market for legacy hardware.

Since Brexit, they've been a lot more strict to "importing". That being said, HK is outside of the EU, so the usual standards still apply. As you're traveling as a private entity (I'm guessing you wen't for personal reasons, not for work?) they'll be a bit more leniant. You can validly argue that the components in your luggage are for personal use. Ultimately, it'll be down to whoever processes the luggage when you hit the UK. As for packaging - if the box and contents match, they won't spend an awful lot of time determining if it's a valid item or not. You have to remember they process 1000s of passangers a day, they don't have time to fully inspect everything that comes through. If you want, I could speak to our courier at work, we occasionally ship from HK and could potentially include it in one of the shipments. Your call.

The size of the memory is in the serial number. KN2GB0C01. 2GB

I need help figuring out the best encryption algorithm / cypher which would best suit short messages, or being carried over communication channels that only allow for short packets of data (EG LoRA, SWARM, SMS, etc). Key requirements: Asymmetric keys - the message needs to be encoded in a way that is signed by one device to only be read by another device using the relevant public key, etc Short length - the encrypted data needs to be as short as possible - such as being able to fit into a single SMS message, or transmitted via the SWARM satellite network Protocol agnostic - it needs to be a method that isn't leveraging the encryption methods of any given communication protocol (HTTPS, etc) - we have to assume the method of "communication" may vary Example scenario: Device 1 is monitoring the temperature of something - ocassionally it has to call back to base with the latest reading. This might be a simple message such as "Temperature: 50c" or whatever. The method of communication may vary, and it may be transmitted via public airwaves (radio, LoRA, SMS, etc). Device 1 knows that the base receiver has a public key of XYZ. Therefore, it'll take the data, encrypt it and sign it against the base receiver's public key. It transmits it in whatever method available to it at the time. The base station receives the packet, decrypts, and processes.

Anything that follows the RFC 1149 standard.

Billion percent this. When it comes to EMC and compatiability testing - everything is driven by gobally defined standards - IEC/BS EN/ISO, etc etc. For equipment to be sold as a means of testing these standards, they have to meet the requirements. So it's not like Seasonic can suggest using a particular brand of testing equipment because it gives them favorable results. They're either going to pass the standards, or they're not.

So today we received: 4 x SuperMicro 5039MC-H12TRF systems (12 blades per system - pretty dense, that's 48 baremetal servers in 12U rack space. This is going to be a royal PIA to cable up properly). 200 x Micron 5300 PRO 480GB SSD (Only item our vendors had in local stock at this volume. Will do for now but longer term will replace with something higher volume. It's non-critical use for our R&D team so not gone OTT with the specs).

I'm pretty sure you have to issue some AT commands to the SIM800L before you get any responses. I'll speak to my lead electronics engineer tomorrow morning. He's spent the last 12 months working on serial communication with GSM modems.

Whatever you do, do NOT expose the UI to the outside world..... I do red teaming and pen testing for a living. You would not believe the amount of publically reachable OpenHAB installations that are exposed to the internet. And worse yet, with zero log in or authentication needed. You can literally load the UI, and mess around with someones lights or whatever else they have sync'd up to it. Just checking Shodan now - there's at least 50 known exposed OpenHAB installs within a 60km radius of my office.

A couple of tests you can perform to determine which side of the network - Client (Your laptop/computer) or Server (Your OMV install). On the Server side, you can run some simple benchmarks to determine a ballmark estimated "upper" speed OpenVPN will perform at on your RPI. I've just done the following on a RPI 3b. openvpn --genkey --secret /tmp/secret This creates a temporary key that you can then get openVPN to run a bunch of benchmark tests with against different ciphers. time openvpn --test-crypto --secret /tmp/secret --verb 0 --tun-mtu 20000 --cipher aes-256-gcm The results should be outputted in seconds. I ran the above on my RPI 3b and got the following: real 0m17.093s user 0m17.079s sys 0m0.012s Take either the real or user result, and use the following calculation: 3200 / <time in seconds> 3200 / 17.09 = 187.24 (Or 187.23Mbps) You can also run it with a bunch of different ciphers: time openvpn --test-crypto --secret /tmp/secret --verb 0 --tun-mtu 20000 --cipher aes-128-cbc time openvpn --test-crypto --secret /tmp/secret --verb 0 --tun-mtu 20000 --cipher aes-256-cbc time openvpn --test-crypto --secret /tmp/secret --verb 0 --tun-mtu 20000 --cipher aes-128-gcm time openvpn --test-crypto --secret /tmp/secret --verb 0 --tun-mtu 20000 --cipher aes-256-gcm This just helps to narrow down if it's an encryption bottleneck (CPU limitations, or resource availability). If it's hardware limitations, then it'll be a bit more complicated to figure out. After that, i'd review OpenVPN's settings. Compression is often a culprit. In /etc/config/openvpn (or /etc/openvpn depending how it's installed) and look for the line that says comp-lzo. comp-lzo should be set to no. You might need to check the ovpn file settings on the client side to make sure compression isnt enabled. Just some things to start with first. It's always a process of elimination.

Windows 11 requires TPM2.0, which in turn needs at least SHA-256. Have them both on and let the OS decide which version it uses. My gut feeling is it'll be 256, as it's more common to find a TPM that supports just SHA-256 than it is to find one that supports both.

Do you have a rough timeline of when this first started happening? First thing I normally do is load up Event Viewer - then go "Windows Logs -> System". Then filter so it only shows errors, warnings and critical. Have a scroll through them and see if anything stands out to you. I'm thinking perhaps CPU sleep states, etc. So if we break down the variables.. you're getting slow Web UI speeds that somehow only improve when you initiate a remote connection (I'm guessing remote desktop or VNC?). This makes me think there is something happening, perhaps the CPU shifting into a different "state" when it perceives little to no activity (idle time). For some reason, it doesn't recognise the HTTP/HTTPS traffic as activity enough to revert back to a higher state, but it does see a fresh RDP/VNC connection as enough activity to "kick" things back into action. When you remote connect to the server, does the web UI stuff remain "usable" ONLY whilst you're connected, or does degrade again the moment you disconnect? If it remains usable for a while, do you know roughly how long it takes until you experience degraded performance again? I think part of the problem here is that Windows 10 is not really designed for "server" level stuff. So there's a bunch of things that could cause this that wouldn't happen if you were using a Linux distro for example.