Making my bed

How hard is it to make my bed in the morning, is it a chore? How do you make your bed in the morning?

[Yes, this is arguably an attempt to make the most dull video possible]

Don't use UPS to ship to UK

I posted about shipping and importing and tax and duty - general info. But this is specific.

DON'T USE UPS!

I had assumed the UPS issue was some minor oversight or administrative error, maybe one they could fix, but no. I got this from the sender (a major PCB manufacturer in China).

It seems UPS need some per sender and per receiver paperwork (like any senders are going to do that?!), and sender doing extra paperwork and notification on every shipment (yeh, again, will any do that).

In contrast, both DHL and FedEx cope. FedEx are not without other issues. Indeed, no carriers are. But these days major international carriers (all except UPS), understand postponed VAT accounting for UK import. They just need the VAT and/or EORI from the shipper. Shippers know how to supply such already (EORI needed for EU I think). I even put VAT number in the actual address lines to be very clear.

But it seems UPS don't just do PVA as normal, they create an administrative nightmare.

Thankfully JLC have said they will add a remark on their checkout for anyone stupid enough to pick UPS for shipping to UK. This should stop anyone else mistakenly using UPS.

So four parcels return to sender, in China, at UPS's cost (LOL), to be resent via a sane courier.

Why?

Well principle for a start - I will not be blackmailed to pay an admin fee I never agreed to, for a service I never asked for, that was provided solely due to incompetence.

But also a simple practical aspect - the fees are demanded on the doorstep and the delivery driver looks ill equipment to provide a formal VAT receipt.

That means my time getting one, assuming it is possible. The web site says "government charges", not "VAT". The customer service email says "tax and duties", not VAT. Without a clear VAT receipt I cannot legitimately reclaim the VAT, and so I won't - we are very careful with VAT (and everything else). I may be wrong, a VAT receipt may be simple, but their attitude gives me no confidence at all.

So the very real risk I will not even be able to reclaim the VAT means this is not just their admin fees. Return to sender and then paying to send via DHL works out cheaper overall. Shame about the delay.

Update:

They said they are returning to sender, and then said out for delivery again. I have no clue what the hell they are up to and that is yet more reason never to use them!

Deliveries from China

I have PCBs made in China (well Hong Kong).

This is all my many small PCB projects (not FireBrick). I would rather use UK suppliers but I am sorry, even for just 5 PCBs, populated or unpopulated, even with carrier charges, China is way cheaper, I mean a *LOT* cheaper, and generally even faster. I'd love UK companies to up their game, and cope, and I have spoken to some, but they cannot get close. If they could get close, I'd got for it. It is a shame.

Duty and VAT

So, I have had to learn how it works. Before Brexit there was some stuff that worked well from EU. But in the last few years things have changed (not just because of Brexit), and now there are some things that are, honestly, better.

If you have ever ordered something as an individual from overseas, and it is over the small "gift" or "minimum" level where they don't care, you will have been hit with a surcharge by the courier. Often on the doorstep as a surprise.

This has three parts potentially.

1. Duty - some levy on some types of goods. The government have a moderately sane web site for this (https://trade-tariff.service.gov.uk/find_commodity) which helps you work it out. The system itself seems insane, and a minefield, but the web site helps. My experience is "duty" never applies to any of the bits we order, thankfully.
2. VAT - this applies always
3. Courier admin fee

The last part if the big problem, in my view. Handling customs, duty, and VAT, is an inherent part of the process of being an international courier. It is no more an unexpected cost than paying for petrol for their delivery vans. Yet, somehow, they decide they will charge the recipient for this admin work and not make it simply part of the cost of shipping.

This is simple for them, as they can legally expect the recipient to pay Duty and VAT so they add their bit. Refuse to pay and they won't deliver. It is a basic lien / or blackmail. In my view it should not be allowed. Royal Mail actually have legislation to allow it (!) which shows that it should not normally be allowed (i.e. if it can just apply normally then Royal Mail would not need special legislation for it).

The recipient has no contract with the courier. They have not agreed a price for service the courier has chosen to provide. Even if they accept they provide the service that is logically the start of negotiation on a fair price. As a consumer even an implied contract like this would be unfair and so not enforceable. But they have you over a barrel.

Postponed VAT accounting

If you are receiving goods as a company, well, as anyone VAT registered, things are better, finally.

It used to be you paid the courier, and their admin fee. You then battled to get a formal VAT invoice from them (not easy if payment collected on the doorstep). Then you included that VAT (not their admin fee) in your next VAT return to reclaim it - up to 3 months later.

End result - not paying VAT. But impacting cash flow, and you paid an admin fee.

Postponed VAT accounting changed that - you account for the fact you should have paid VAT on imports, and that you are claiming it back, in the totals on the next VAT return (surprisingly not separate fields for that). But you don't pay VAT on import. Obviously they get the tax when you finally sell with VAT at the final (higher) price.

This gives the courier no excuse to charge an admin fee - yay!

DHL, FedEx, UPS

The three main couriers used by JLC seem to be DHL, FedEx, and UPS. They have different prices and delivery speeds. FedEx is arguably the cheapest, and works (though hassle with them insisting on a signature). UPS are next. DHL cost more, but probably fastest. Until recently I was using DHL. I made the mistake of trying the others.

• DHL are quick, text/email progress, text/email on the day with time window, even live tracking the van, cope with leaving on doorstep if I ask, and handle Postponed VAT Accounting no problem.
• FedEx are OK, not the same progress messages, struggle to "leave on doorstep", but do handle Postponed VAT accounting
• UPS are idiots. Slow. No updates. And it seems have no clue on Postponed VAT accounting, so insist on charging on delivery, and their admin fee is expensive (more than difference in courier costs).

So, obvious lesson, do not use UPS, as they cost more in admin fee than it is paying DHL to send in the first place.

Don't use UPS, simple as that!

In practice the few orders using UPS in the pipeline are literally going to be returned to China, at UPSs cost, if they cannot work it out, and then I'll pay for delivery by DHL. This is slightly more than UPS admin fee, but it is the principle - I want UPS to suffer the cost of returning to China for their stupidity, and I've learned to never, ever, use them again, and tell you the same.

Just to add, we now have several supposed "delivery attempts" which I can prove with extensive CCTV were not, in fact, attempted, by UPS, over the last few days. Why do that?!?

Pre-pay

Another option is have JLC send via a courier but with pre-paid duty. Same set of couriers.

This is bad for several reasons - for a start the extra they charge up front is not the normal 20% VAT. It seems a random and larger amount. I have no clue why! But also it is not a VAT invoice, so you can't easily reclaim the VAT! To be fair getting a VAT invoice from couriers paid on receipt is not easy either.

It may work for an individual who cannot reclaim VAT, as may be cheaper done this way than VAT and admin fee on receipt. So worth considering in such cases.

Duty

I mentioned duty. This is not the same as VAT (which a business can reclaim). You have to pay it.

Duty applies on some specific classes of goods, from specific countries, and it really is very specific! It is basically politics.

Thankfully JLC are not totally daft - I can say the category for the goods, ensure it is right, and not have duty charged. I only got that wrong once, and had a couple of pounds duty (plus a courier admin fee)!

If you have to pay duty, tough, it may be that with enough imports an "account" somehow with chosen courier can avoid admin feeds for these. Not 100% sure. Thankfully we don't do stuff that needs duty.

It is nice that JLC offer a clear choice of couriers.

What is really nice is when sender will work with you to ensure clear and accurate marking of the goods. For a recent order from China (not PCBs this time) I searched on that duty checking page and identified the exact description and "category code" and the sender agreed to clearly use that wording and code on the parcel to avoid issues. I hope it works (will find out in 30 to 60 days).

FB9000

I know techies follow this, so I thought it was worth posting and explaining...

The FB9000 is the latest FireBrick. It is the "ISP" high end model we do. We do smaller models like the FB2900 as well, but FB6000 and now FB9000 are aimed at ISPs and the like. It is what A&A use.

You can see a lot more here: https://www.firebrick.co.uk/fb9000/

But why now - the FB9000 has actually been around a while?

We are not like other companies!

When we launched the FB9000, we obviously started using them ourselves, in A&A.

We hit some snags, some random crashes, we backed off, we found a release of the code that worked and was stable, but that does not address the underlying cause. Why did some releases crash? So we were able to continue with a good set of working LNSs on a somewhat aging reliable release of code. But it meant some inconvenience for our customers along the way when we tried other code. We do not like that! So we massively backed off.

Thankfully some devices, notably BGP routers with VRRP, which annoyingly crashed far less often, can recover in literally 1/10 of a second. So they were good test cases for new code without upsetting customers. An LNS does not recover as well as all users need to reconnect and that can take minutes, depending on their router.

You would not believe the details behind the problems, seriously, it is crazy, and I am not even going to try to explain it here. There may be a really detailed technical blog post by the FireBrick team in time. Suffice to say this snag held us back something like a year.

Now, we could have plowed ahead, and sold loads, but we were really careful not to. A couple of ISPs trust us enough to solve it that they have the stable code release running and did buy some. Thank you. They did so very aware of the issues and have been fine on the stable code release.

It takes time

The issue is that the fix literally takes months to be sure it is a fix. And at A&A we have been doing very very careful staged upgrades to LNSs to prove this, with a lot of staff working during the night to manage this (well mostly one, thanks Andrew). This has taken months even after we think we have nailed the underlying issue. Thank you to all of the staff involved.

We are now at the stage we can probably say it really is fixed, at last. But it is one of those things which are a problem - you cannot be 100% sure until it doesn't crash. Yeah, when exactly is that?

Chasing ghosts

We really are pretty damn confident now. The issue is that, as an engineer, you want to find the smoking gun. This issue is a horrid mix of hardware quirks that even the chip manufacturers cannot explain, and some very very subtle hardware initialisation that has impacts days, weeks, even months later in running code. We have found some concrete issues, well, things not quite 100% as they should be, but not the causal link you want between such things and the problems we saw. And this is not for a lack of trying - every time we thought we found the cause the team have tried hard to break it in a repeatable way. To overdo what we may possibly have done wrong.

A product we can sell

This has always been an awesome product, and any other manufacturer would have fired off the marketing team years ago for sell - sell - sell.

We finally have something we can say with a lot of confidence works well. Does the job, and does it well.

There is more

The FB9000 is awesome, and if you are an ISP you really want one - they have some unique features that really gives A&A an edge which you too could enjoy.

But we are working on a next generation for the smaller units, the FB3100 to succeed the FB2900. It too will take time, and we hope none of the same issues. The FB2900 is also awesome, and there are some offers I think on the pricing soon.

Audio sync

Should audio sync be an issue?

Well I would hope not.

The way I do it is that I record video with my nice Canon 1DXIII which has audio, and audio with an audio recorder on my shirt, and tell final cut pro to make a synchronised clip. Simples.

The camera audio is not good, it ends up with mechanical noise from lens focus, and echo, but the audio record on a shirt mic works well.

I have since changed from using a Tascam and radio mics to my own audio recorders for my shirt.

But someone asked how to sync audio with my new recorders?

I was "well, sync to the (crap) audio on the camera", which fooled them as they were talking of sync of raw video only and raws audio only.

So I made a feature. My audio recorders will now make a clear 1s tone at start of audio and exactly aligned a clear red LED on the front.

This makes aligning video and audio easy.

But I never expected to use it. Well, until I did.

I recorded a video, direct on final cut pro, on my mac studio with monitors, and weirdly they have bad audio sync!

P.S. someone said would be nice of LEDs off during record, and now that is the case for dark mode.

ESP32 SD Card wiring and driving

This is so that people like me find it and know what I learned.

Making an ESP32 board with Micro SD slot, in my case specifically an ESP32-S3

First step, wiring up. This is what I have ended up with.

There were other stages, including just the pins you need for SPI mode, which mean no SDDAT1 or SDDAT2 lines. But with them having a pull up anyway. For SPI they have different meanings and labels, typically. The other stage was no resistors.

Resistors or not?

This is complicated, honest. After lots of reading of all sorts of pages and comments it seems...

• The resistors are part of the spec, so highly recommended.
• The resistors are needed for the default, old school, initial (slow) mode by which SD cards work as they use open drain driving (pulling down only) and need resistors to return signal back up. But, you don't stay in that mode - you switch to a mode where pins are driven both ways, so why does it matter?
• Some cards even have internal resistors, it seems. But no ideal which. So some may "just work" anyway.
• The ESP32 has an option of pull up resistors, but these take time to rise, and so do not work well if you have no resistors - the practical impact is really slow data transfer (using SPI mode) - but otherwise working. You can actually work around this with driving the CS in SPI mode low rather that using the library, it seems, at least for SPI mode working.
• The resistors also help avoid odd power usage on floating pins even if not being used, but again, you change mode to one that does not use open drain.

End result, just simpler to have the resistors, even if that means squeezing them in on a small PCB.

GPIOs

This is 7 GPIOs, a lot, but they can be mapped to adjacent pins, and the right order, to connect directly to the Micro SD card slot. SPI mode could use only 5 if needed, but best to have all the pull ups anyway.

SPI or MMC control libraries

Lots of examples of SPI wiring and SPI drivers, leaving some NC pins or leaving them with just pull ups. This is what I started with. But it was not as fast as I wanted (reading and writing around 250kB/sec).

It seems the MMC drivers are way faster, simpler as that, even when using 1 bit. I now have boards coming with 4 bit working to compare. With one bit I am writing 350kB/s and reading 750kB/sec, so may be the specific SD card is slow - more tests needed, and will be interesting to see 4 bit mode -  I'll update this post.

Small LED strip boards.

I have these. 

The idea is small, really small,. LED driver, ESP32-S3, but small. Power from strip 5V-35V, so a switch mode supply.

To do that no USB, not USB-A or USB-C. I have used TC2030 pads.

But to allow those wanting to solder manually, pads for that as well.

We are talking 27mm x 16m LED controller.

Fun with... LED Strips

I am not late to the party here, honest. I have been playing with these for some time, and even design and make LED controllers.

The ubiquitous protocol is "WS2812", which is basically a serial data stream on one data line at a rate of around 1MHz with short or long pulses being 0 and 1 as data, and a long gap being end of sequence. The exact timing in the various data sheets do seem to vary slightly. SK6812 is similar.

The data sequence is binary values, 8 bits per byte, and the bytes that are each colour. The exact colour order varies depending on chipset it seems (patent/copyright/god knows why). In general it is Green, Red, Blue, but can be Red, Green, Blue, and I have seen others.

Each device consumes its data sequence for its colours, and passing on the remaining stream. Once the long gap comes all devices load the accepted colours to their LEDs simultaneously, which is cool.

There are also RGBW, which have four bytes not three, so include a "white" level. This is cool (or warm) as the white LED is often larger, and brighter, and the power of one LED but white (doing white with R+G+B is not as nice a white, and uses 3 times the power).

Coding for this is simple, and ESP has ways to do it - typically using the "remote control" system for IR remotes, but can also be done using SPI bus with a little fun with the logic. This allows working with many devices as a serial stream via SPI is very simple.

They also get smarter with some designed to take a backup data which is a connection of the data in to the previous pixel. If the backup comes in without the expected data, it can accept the backup, one pixel later, as its own data, and pass on as such. As such a single dead module does not break the chain.

So, we have many choices, the exact chipset, the order of colours, if white included (which flavour of white such as cool, warm, natural, etc), if backup line, and voltage.

The voltage is a fun one - commonly 5V, the voltage drop over a long strip is too much and you lose blue, then green, so have to inject 5V at multiple points in some cases. But 12V has options - one is 12V drives three sets of RGB LEDs in a chain, so 3 "pixels" the same, but another is 12V works one "pixel" (the WS2815 range do this). I have, however, some that work on 3.3V (impressive for blue) for on board LEDs, and I use these all the time on my PCBs - they would not work on a "chain" of LEDs off the board.

What would be nice, and I am not sure I am quite seeing yet (please say if not), and seems the logical conclusion here would be.

• 12V supply (working all the way down to 5V or less)
• Per pixel control (not sets of 3 pixels together)
• Backup data line
• RGBW option so white on the pixel (in choice of colour temperature)

It looks like the last point is the sticking point from what I read, as WS2815 does the rest, but when finally common place, that will be the ideal solution. The 12V working allows long strips on single supply. The W allows lower power and brighter "white" as functional lighting. The per pixel control is obviously better. The backup is obviously prudent. It would be extra cool if it can run from 5V on the same chipset, just obviously suffering the voltage drop issues over a long run.

For extra fun, I tested the WS2815 (12V) modules and they work very happily from 5V, so allow a hell of a lot of voltage drop. The data sheets say +9~+13V