The KeyProx model contains two logical devices, the keypad itself and the RFID reader. Logically these appear to be completely independent, though a quick look in the case confirms there is only really one device as you’d expect. This means the keypad information will be the same for a non-prox model. The prox part will probably be the same for the separate max3/4 RFID reader but I don’t have one of those to compare against.
The device ID is set using the rotary selection switch on the PCB. Although it has 16 positions only 0-3 are valid for keypad ID. Positions 0/1/2/3 correspond to RS485 bus IDs of 10/20/30/40 respectively for the Keypads and 90/91/92/93 for the associated prox readers. A strange pair of numeric sequences. You’ll also note from the startup polling sequence in my previous post that the prox readers are polled separately from the keypads and in reverse order. I’ll just deal with the keypad in this post, as I haven’t played with the prox reader much.
I always fancied adding Ethernet to my home Alarm system, even though I don’t have any particular use for it. I live in a pretty safe area and it rarely has false alarms or anything else I really need to monitor. Besides, if you’re at work, miles from home and in the middle of something, what what are you going to do if you get a notification that your house alarm has gone off?
Eventually, by chance, I picked up a second hand official Ethernet adapter for the alarm at a car boot sale, but it turned out the firmware was too old and the cable to update it is surprisingly expensive, and the update itself not publicly available anyway. I was already aware of the LCE-01 from SM Security Alarms as a cheaper alternative, with more functions like a Virtual Key Pad app, but £66 for a device I didn’t really have a use for was still a bit steep for someone who hates to part with money. I contacted the maker to find out about updating the firmware on mine and he offered me a good deal on a part exchange so I went for it. Continue reading Honeywell Galaxy G2 RS485 Bus→
The escapement works – it’s alive! The escapement has been installed and the lifting arms trimmed to the correct length. According to the books we’ve read the pendulum should swing 3 degrees (each way), but nowhere does it say what positions the arms should be lifted to before the pendulum reaches them and how much further they should be moved by the pendulum. The more they are lifted by the pendulum the more energy the pendulum will lose on the upswing and so the less of a push, relatively, will be given to the pendulum on the downswing. This was a simple bit of trial and error, positioning our temporary pendulum manually (the arch pattern was helpful for holding the pendulum, see the pictures below) and seeing where the arm rests on the block and how much the block moves with the rest of the swing. The result we were happy with was lifting the arms to a position reached with the pendulum at 2.5 degrees. This let the arm of the escapement sit about about a third of the way on to the block. When the pendulum pushes the arm the rest of the way to 3 degrees it moves the block enough to unlock the escape wheel with a reasonable looking clearance.
I have uploaded two videos to YouTube showing the escapement in action. In the first video the clock would only run for 5-10 minutes at a time. In the second, after all the new parts had bedded in a little it will run for hours. The blocks you see next to the bracket are in place of the banking pins, which haven’t been made yet. There is a extra collar on the pin at the bottom of the left arm because the arm needs a slight tweak to it’s angle. The pendulum is temporary and too short, so the clock is running faster than it should.
It’s been a while since my last post about the turret clock restoration project, not least because there wasn’t a lot of progress over the winter. For a long time we were struggling to work out how the double three-legged gravity escapement itself was constructed. Unfortunately, several offers of help with this didn’t come through but we have managed to work something out that that fits the brief. As always there are a number of ways something like this could be done, but we wanted to replicate the original. Visually we have done that so we must be pretty close, but we don’t know how close.
The method we used was to turn down a hexagonal bar to make the arbour, leaving a short hexagonal section on which to mount the two escape wheels. The hexagonal mount gives the wheels good solid attachment to the arbour preventing any rotation as they hit on to the blocks and stop moving. We can see no way that they could have been pinned to a round arbour and we didn’t think silver soldering them would be sufficient due to the repeated blows they must endure. A small section of brass tube fits over the hexagonal section between the two wheels to keep them the correct distance apart. The three lifting pins are installed between the two wheels in simple holes straight through. A boss fits on either side to sandwich the wheels and tube together and keep then in place, as well as covering the pin holes to keep the pins in. The bosses could be pinned to the arbour, but they don’t appear to be on the original. The arbour isn’t a large diameter and the bosses don’t have a lot of depth to take a pin. As they only need to hold the parts of the escape wheel together, they don’t take any force, we decided to silver solder them on to the arbour. Overall we think our construction technique must be pretty close to that used on the original, but it’s hard to inspect this part on a working clock – our reference clock is viewed from eight feet up a ladder, with the escapement at the back and everything is moving.
If you’re building your own Linux based router to connect to BT Infinity you’ll probably want IPv6 working too. Address assignment works differently in IPv6 to IPv4 – we aren’t going to be given a single address we are going to be given a 56 bit prefix. From a 128 bit address that leave us a lot of bits available to use to address hosts on many sub-networks in our network. We are going to assign 64 bit prefixes to our interfaces (we can create 256 prefixes at 64 bits each) each with vastly more addresses than the entire IPv4 address space. To get our prefix from BT and delegate prefixes to our own networks we need an IPv6 DHCP client. This is where lots of other guides, forum posts, and the like, are a bit out of date (or don’t apply to BT Infinity) using wide-dhcpv6, dibbler, radvd, sysctl settings and custom scripts. Having played with various options I’ve found what works for BT Infinity in 2017, resulting in a really clean and simple method that boils down to a very simple configuration.
Just a handy tip if you’re using BT ADSL with an OpenWrt router. I didn’t know you could get an MTU of 1500 on ADSL. I have that on my Infinity connection at home, but it wasn’t until I played with the router at my Father’s that I found it was possible on ADSL too.
Why do you want an MTU of 1500? Without going into all the technical details of Ethernet, here is the simple version: Your home network (wired or wireless) is Ethernet based and as standard Ethernet uses packets of 1500 bytes but traditionally ADSL routers in the UK were configured to use 1492. This meant any time you sent a full size packet to the router, to forward on to the internet, it had to break it down in to two packets. This adds overhead and is inefficient, resulting in reduced throughput (slower speeds).
If you are using OpenWrt connected to a modem that supports an MTU of >1500 you can fix this. I suggest the OpenReach white modems originally provided for Infinity, which can also be configured as PPPoE modems to connect an Ethernet OpenWrt router to ADSL.
To get the MTU up to 1500 for the PPP connection you need to increase the MTU of network interface to 1508. That’s easy, simply edit the WAN interface in the OpenWrt Luci GUI (no need to edit WAN6 as well). Or edit /etc/config/network (example from Netgear WNDR3700, interface names will vary by device):
This will only set the MTU for the physical interface. The PPPoE connection will still use 1492 and there doesn’t appear to be any way to fix this in the GUI. So add the following to a new file called /etc/hotplug.d/iface/99-mtufix (you’ll need to connect via SSH to do this):
[ "$ACTION" = "ifup" ] || exit 0
[ "$DEVICE" = "pppoe-wan" ] || exit 0
logger -t mtufix "Setting MTU of $DEVICE to 1500."
/sbin/ifconfig $DEVICE mtu 1500
This is a quick first look at the gravity arms for the escapement. Unfortunately we have no direct plans for these arms, although the principal is explained in a number of book that we have along with generic designs. We also have limited access to another Smith clock with one, but the people of Duffield would probably not appreciate it if we stopped the clock and dismantled it to scribe around its parts. As a result these have been made from a combination of reference books, awkwardly taken part-measurements and careful study of our own photographs.
I’m not going to include any technical details yet because we don’t know if they will work! We hope this won’t become a process of trial and error but there might be some fine tuning to be done at least. I’ll post more pictures of our progress and details of any problems we find as we continue. Once we have it working I will, of course, provide proper details. These arms have been made from multiple parts welded together which I don’t imagine is how the originals were done, presumably they were cut from a single piece. However, this technique has made them a lot quicker and easier to produce (important since we might have to make more variations yet, if they don’t work) and the results look fine. Even easier would have been getting access to a water-jet cutter, then we could have just drawn them up on the computer and a few minutes later had a perfect set pop out of the machine.
A quick post to show the new pendulum suspension. This is a departure from the square version on the St. Alkmund’s church clock, but it’s been made to plans from Smith of Derby so it is an authentic design (if only we had plans for some of the more complicated bits, like the escapement!). There’s no way of knowing which design this clock would have had originally, so I’d be happy with either.
It’s surprising just how heavy this bit is, but it’s nothing compared to the weight of the whole pendulum. In actual fact we don’t know what the pendulum bob should weigh, but it’s a fair estimate to say it’ll weigh quite a bit. I really hope the new casting was well made, because all that weight is going to be hanging off it!
The current bolts are temporary ones and that is not spring steel connecting the two parts yet – we’re having trouble tacking down a source of suitably sized spring steel strip (at a sensible price). You will also notice gravity arms have been added, as well as the brass plates that hold them, but more on that in another post.
The double three-legged gravity escapement uses a fly to dissipate some of the excess energy in the system. When the escapement unlocks the legs of the escapement move 60 degrees before coming to a sudden stop again. The fly helps to reduce the acceleration of the escape wheel and, like the fly on the striking train, needs to be able to continue to move a little when the arbour stops suddenly. Unlike the bigger fly this one doesn’t use a ratchet, instead it uses a friction device. We need enough friction that it gets turned with the arbour starts to move, but when the arbour stops it should be able to slip and come to a natural stop. The fly was made from a drawing supplied by Smith of Derby when my Father visited them. It’s no coincidence that it looks just like the one on the St. Alkmund’s church clock.
The pictures below show the completed fly, with a bolt through the middle where the arbour would normally be – which is why it looks a little wonky in some of the pictures.
My recent post on how to change the CID on a Samsung Evo Plus SD card has generated some interest, but also a number of people who are having problems with it. I thought it was worth posting an update with some extra information. First off, I suspect some people who are struggling have fake cards – there are a lot out there and some of them look pretty convincing. Others have suggested different hardware / firmware revisions might be an issue – quite possible but I have no way of knowing (all my Evo Plus cards work, so I can’t can’t compare against ones that don’t). I can see no reason why different phones etc. would give different results – as long as it’s a proper SD controller (not a USB mass storage adapter) then sending the command should work just fine.
These are very common and if you google for fake Samsung cards you’ll find lots of info on how to spot them. A few tip I’ve picked up along the way:
Packaging quality – the image should be well printed, in high resolution and good bit depth on the colours (some fakes looks like they’ve been converted down to 256 colours). The gloss overlay over the printed areas should align with the printing below them, if it’s offset that’s a bad sign.
Packaging info – the product information should be correct and match the card. I had one fake that incorrectly stated a 32gb card was SDXC on the pack instead of SDHC, the card itself had SDHC printed on it. The correct size should also be printed on the packet. Look up the UPC from the barcode on the back and make sure that matches the product and size of your card.
Hologram, with scratch-to-reveal verification code. The real ones have them (recent ones at least), fakes might but probably don’t. All of mine have, but oddly enough when I tried to check one on the Samsung China website I didn’t get anywhere with the verification code, the site was in Chinese though so I might have been doing something wrong.
The card – lots of subtle details to check. Smooth back, not lumpy showing circuit parts beneath the surface. Black on the back, white on the edges. Slight bevel on the contact side, to help insertion. Correct info printed on the card. Correct font, especially for the capacity digits, some fakes don’t use the correct slim font. Text on the back is printed so it is read with the card contacts end pointing upward. Mine are made in the Philippines but this is probably not the only place so don’t get hung up on this.
Card CID – check it and compare to working ones. See below…
An example of the CID on one of my cards: 1b 534d 3030303030 10 98625deb 0102 a1. Your card CID should be very similar. The manufacturer ID should be 1b, followed by an application/OEM ID of 534d. The product name is 3030303030 (5 x ASCII ‘0’). The product revision is 10 (1.0). The next 8 hex characters (98625deb) are the SD card serial number, yours will be different! The manufacturing date is next (0102, or 0 10 2), where the first digit is ignored, the next pair is the year in hex since 2000 and the last digit is the month in hex. So this is February (2) 2016 (2000 + 0x10). I also have March 2016 (0103) cards that work fine. Last is the checksum (a1) which will be different on your card. I doubt many of the fakes have properly set Samsung CIDs so hopefully this is an easy way to tell.
My cards / System
Samsung Evo Plus 32gb. UPC: 8806086928410. Model: MB-MC32D. Model code: MB-MC32D/CN. Purchased from this listing on AliExpress. I am not affiliated with the seller and get no referral commission from this link. I also cannot guarantee that you’ll get working or even genuine cards, but I have purchased on two occasions from this seller and the cards have been genuine and worked with evoplus_cid.
I have used evoplus_cid on a Samsung Galaxy Tab 2 (10 inch, wifi model, p5110). The tablet is running CyanogenMod 13 unofficial from here.
I’ve made a couple of updates to evoplus_cid. If you supply a full 32 digit CID (and don’t apply a serial number modifier) it will be written as is without recalculation of the checksum. This was requested by a user for cards that apparently always had a checksum of 00. Although, I’ve got a laptop that always displays 00 for the checksum when showing the CID, so I wonder now if his cards really did need that! I’ve fixed a bug when compiling on 64bit Linux that could prevent the CID being written. I’ve also fixed a bug causing the displayed CID to include some extra ‘FF’s.