Stung by the Stingray?

This is an old draft I had sitting around and is probably relevant only to cellular technology mostly extinct in the wild, but some may remain applicable.

The tools I used to view the site locations included AIMSICD which may not be in active development anymore.

Part two of Urban Police State Week!

Note: This is very CDMA-centric. CDMA is used by Verizon and Sprint. Only reason for this? I don’t have a GSM phone. Sorry!

Welcome to the creepy, mysterious, bizarre world of covert wireless phone surveillance.

Stingray 1 and 2 - from Ars Technica
Stingray 1 and 2 – from Ars Technica

Please note that even though I’m using the name “Stingray” here, there are a lot of different devices, apparently — some obsolete, some completely mysterious… What’s common to all of them is that little to no documentation on them has been made public. For quite a while the FBI wanted these entirely secret, but now they’re starting to waffle on their policies since evidence of illegal warrantless surveillance by local law enforcement agencies has leaked.

Here’s a late 2013 article on the devices – this predates widespread LTE rollout on Sprint, so there may be new stuff in place (as I may have personally observed, if I can make sense of these damn tcpdump captures).

Anyway… “Stingray” is kind of vague. It appears to be software upgradeable to gain different capabilities. Its most basic functionality is as an IMSI catcher – it mimics a valid cell site momentarily with a good strong signal, and it causes phones to try to register with it. When the do, it logs their IMSI number, which is a unique hardware ID. It appears that there’s another component or two of the system that can perform radio direction finding to track down a single user, likely in conjunction with traffic being used to fake the handset into transmitting a lot.

So here are my personal observations of devices that have been used around here in South Florida. Since I do not, and probably never will, know what actual devices or software versions are in use I’m gonna make up my own stupid classification system! Bear with me now, my writing style is unique and silly.

The Miami Heat Special – Primitive, Clear As Mud!! (2008 – 2013)

This one first showed up intermittently during Miami Heat games leading up to the NBA playoffs before finally just coming online during almost any major event at the American Airlines Arena in downtown Miami.
Range: Short. Only covers a block or two around the west side of the AA Arena. Exact deployment location unknown, but unscientifically narrowed down to Marina Blue, possibly in a nearby vehicle.

Noticeable behavior on user handset: Almost nothing works! Phone calls will drop whenever the IMSI catcher wakes up, every minute or so. Mobile data connections drop out (“Data Call Failed” messages possible). Outgoing SMS tends to get lost without a trace. Symptoms seem almost identical to severe network overload – HOWEVER, if you look at the SID, it will be an oddball one that never appears otherwise. It seems like a random SID got picked out of a hat each time this one is deployed. Unit reports no location or bad location (0, 0 in East Atlantic Ocean).

No Data For You! Smart Yet Dumb And Dumber. (2009-present)

This variant shows up at random and I’m not entirely sure just what it is. It does appear, however, to be the first variant I’d seen that was actually smart enough to properly fake the SID and coordinates of the host site. However, one thing it seems to noticeably do wrong is that it will not relay a site’s wildly incorrect position!! If it’s put up near a host site that would otherwise report 0,0 or something equally dumb, IT WILL ACTUALLY TRANSMIT ITS OWN LOCATION OVER THE AIR!!! Usually, it neatly reveals itself as being run out of a parked van. Its behavior if deployed out of range of host networks is unknown to me.

Noticeable symptoms: On some handsets, CONSTANT “Data Call Failed…” messages. Others suppress these messages as they’re like the worst game of whac-a-mole. Mobile data connections may work momentarily, but will usually cut off before you can do anything useful. Text and voice still work. Presumably, this is also the first IMSI catcher that does not break 911/emergency calls AND tries its damn best to provide valid geographical info for E911/GPS assist — it’s… the kinder, gentler IMSI catcher.

Monkey In The Middle – Nice try, log it on off. (2010-present)

This one is actually smart enough, so it seems, to pass through some mobile data with manipulation. However, the data it sends is complete corrupted bunk and causes applications to logout and crash. As this happens, the flow of useful information and traffic from the device slows to a crawl or stops entirely. This one seems to destroy SSL sessions in most cases but doesn’t affect unencrypted connections (may sniff traffic?).

Noticaeble symptoms: Applications fail. No “data call failed” message, traffic flows okay, but nothing can usefully communicate or login. Voice tends to suffer dropouts. SMS ok. Location of host tower is relayed including invalid tower locations. Randomized bunk SID.

The Blip (2006-present) – Blink and you miss it

This one is really, REALLY hard to figure out. See, with Sprint, so much is utterly and completely broken that it’s hard to tell if you’re looking at manipulation or just the network’s inherent brokenness.

Noticeable symptoms: Very brief dropout/stall in voice or data calls. Infrequent. Weird SID seen in logging tools.

Subchannel flatulence

Quality observation by my fellow engineer (also a radio survivor):

Music that’s been previously compressed to mp3 sounds like butthole on an HD Radio channel.

Music that’s been stored and played out uncompressed sounds like mere butt cheek on HD Radio.

And here I was thinking it just sounded like a foam cloth top brush with too many pieces missing.
Picture unrelated.

Revisiting the Printrbot Simple Metal

The Printrbot Simple Metal was a really cool design. It’s a Cartesian 3d printer built like a brick house by Printrbot out of Lincoln, California, who went out of business facing powerful competition from a lot of low-cost Chinese printers but recently decided to get going again. One of my coworkers had one that had an old version of Marlin on it (1.0.0?!) and I wanted to update it to improve on some features and add support for a heat bed.

oh she’s a brick—– house

It was available with or without a heated bed, and even if you didn’t have one, it can still be added easily using a stick on heater mat/thermistor like this. The connectors are present on the Printrboard controller for it. One cool thing about the Printrboard: it has two big beefy mosfets onboard, and the DC in connector just mates straight to a standard ATX12V connector on a PC power supply. All you’d need to do to power the Printrbot is go to the ATX motherboard connector on the supply and jumper the small green wire to one of the black grounds to make it auto start. On Rev. D boards, this was a 4 pin; on Rev. F, it’s 6 pin.

There is a solder jumperable pad, supplied OPEN, for USBPWR 5V. This will allow the board to power up from the USB host it’s plugged into. Don’t jumper this unless you have a very good reason to for your configuration. An onboard switching regulator will supply +5V to the components onboard once +12V is input to the ATX12V connector.

This is based on the RevF board, as that just happens to be what landed on my bench. Printers using the RevD are not uncommon too, apparently.

Steppers: The board supplies four Allegro A4982 stepper drivers, an improved version of the A4988. These do not have a heatsink on them like a lot of newer boards do, but I haven’t seen them get hot either. It certainly won’t hurt to add some stick-on sinks if you want. The datasheet suggests that the lion’s share of the chip’s thermal dissipation goes out the bottom though. The driver type in Marlin should be left on A4988 as the I/O behavior is identical.

Microstepping IS supported on this board – you will find a small solderable jumper pad next to each driver. If you solder bridge that entire pad, you will get 1/8 microstepping. On this particular printer, all four are un-jumpered and microstepping is not used. On a printer that was NOT built like a brick house, this would lead to it having a very loud sound about it. On the Simple Metal… it just sounds smooth and sweet. Don’t forget to change your steps per unit if you bridge the microstep pads! The VRef voltage that sets the stepper motor current comes off a DAC, making the motor current adjustable in software. I haven’t experimented with this yet or found any reason to move it off defaults – the motors and drivers stay cool and I am not experiencing any skipped steps, even when making the printer SCREAM at 150mm/sec! (it will DO IT with the stock hotend and not skip any steps, but you will lose detail. Dang.)

Updating Firmware: Before updating, if you’re doing this on an already functional machine, get your EEPROM settings with M503 and copy them into a text file. Otherwise you’ll wind up with defaults that may or may not be correct.

The CPU and serial interface: Another cool thing about the Printrboard: Unlike many ATMega based 3d printer controllers that came out at that time, the ATMega AT90USB1286 has native USB support. This will prove to be a double edged sword but won’t stop you from having fun with this board, read on. A Marlin build bug may show up when you’re trying to build as a result of this unique platform target. This is currently fixed in the nightly “bugfix” branch, so start from that if you are compiling Marlin yourself.

There is a “BOOT” jumper next to the chip. If you jump this and press the reset button, the chip will come up in DFU mode. It comes stock with a bootloader from Atmel that supports their FLIP utility for programming under Windows. (Todo: figure out what tools would be needed for this on other platforms.)

Dealing with Windows Being A Stupid Doodiehead As Usual: To program this chip, download Atmel FLIP and install it. On Windows 10 64-bit, get the version with the JRE included (as documented here). Tip the Printrbot over on its side and place a jumper cap on the BOOT pins, then press the reset button. You should see Windows detect the AT90USB in DFU mode— however, it may not properly install the driver. Open FLIP and click the USB cable icon in the toolbar, then choose USB connection. If you receive a message about a missing DLL, close FLIP again, and go into Device Manager. Right click the DFU device that’s showing up with a warning icon and choose Update Driver, then manually choose the location. The driver will have been dropped in C:\Program Files(x86)\Atmel\Flip [version]\usb. It should install ok, then Flip is ready to use.

To flash a file with Flip, go to File > Load Hex File. Click the USB plug icon and select USB connection. It should identify the AT90USB1286 if the chip’s already up in DFU mode. By default the options on the left will all be checked except Blank Check. That works fine… make sure it’s set to write out the Flash space and not the EEPROM space (the button in the top center toggles this), then click start at the lower left. It’ll take about 15 seconds to complete. IN THEORY, you should be able to reset out and run the newly programmed application in the chip with the button at lower right, but that doesn’t work for me – probably because the BOOT jumper is still set and it just loops back into DFU. Pull the jumper and press reset, and Windows should detect the

I have provided two compiled versions here at the end, one for printers with a heated bed and one for those without. The version for printers without a heatbed bed will work fine on those that do, you just won’t be able to heat the bed. The other way around, I suspect, would make it refuse to work with a MINTEMP error being thrown.

Building Marlin: I used PlatformIO and the Build Marlin addon tool. You can also use the Arduino IDE after installing Teensyduino. (Board type will be Teensyduino++ 2.0!). My configuration files are at the end of this post; my changes were mostly to invert the inductive probe output behavior (which MAY have been different for Rev. D boards!) and to add bilinear bed leveling with a 16 point probe. I tried using the new Unified Bed Leveling architecture but it caused the code size to exceed available memory. Bilinear is working fine on the machine here, so I’m just using it 🙂

Yes, you can buy that funky UBIS hotend and parts for it. The distance between the nozzle and probe center-to-center is 25MM, I’ve checked this and included it in the configuration file.

I have a sneaky suspicion that the example configurations for Marlin 2.0 just haven’t been touched since shortly before/after(?) Printrbot blinked out of existence and the example was only built and tested for the Rev. D Printrboard. A bit of searching around online suggests that the big change between D and F was the addition of a buffer transistor for the input from the inductive probe, which was prone to damage on Rev. D. If you have Rev. D, the stock config should be fine, but I think the buffer basically inverts the input. The way to tell will be to try homing the printer with G28. If the Z axis rises, pauses, then rises again, but never comes back down, use M119 to test the endstop input states. If the Z axis is not at the bottom and the LED on the proximity sensor is out, it should not say TRIGGERED for the Z endstop. Place a metal object under the probe so its light comes on and check again, it should say TRIGGERED. If you get the opposite behavior, you will need to toggle that state. The relevant lines are #define Z_MAX_ENDSTOP_INVERTING and #define Z_MIN_PROBE_ENDSTOP_INVERTING. These must match or it will toss an error on compilation.

Verification and Final Settings: Once you have the firmware loaded and running, open your terminal of choice. You can use Pronterface, the G-Code terminal in Octoprint, RepetierHost, whatever works.
Send M115 to get the firmware version.
If you previously had an older version of Marlin installed, send M502 then M500 to load the defaults from the firmware to the EEPROM space and save them. If this printer had an LCD (it CAN be added!) it would prompt you to do this from the front panel on first boot.
PID autotune: I usually start the fan first with M106 S255. This may not be necessary but I find it helps on some platforms.
Start the tuning routine with M303 S215 C8 U1
(8 cycles to 215 degrees C, and the U1 flag will save the values to RAM)
M500 to save the results to EEPROM for later use

Bed leveling: If you have a heatbed, heat it first to a normal use temperature (say, 50C for PLA) and let it stabilize a minute before continuing. The hotend temp won’t matter for now as it’s not going to affect the inductive probe.

(this will auto home all three axes)
(a magical dance will begin)
If you already have a working Z probe offset value from your old settings, enter it now
M851 Z-0.7 this will vary by your printer and build surface

Once G29 is done, it will output a small table of the measurement values. Save the results with M500. Re-home with G28
Test the Z height by heating the hotend to a normal use temperature, placing a sheet of paper on the bed and sending G0 Z0. It should kinda just grab it. If you need to adjust it, check these instructions.
If your extruder is stock, well…. for the FIRST TIME EVER… and that is to say I have literally NEVER seen any other Chinese printer I’ve worked with factory calibrated correctly…. YOUR E-STEPS ARE PROBABLY CORRECT!!! See, this was why you paid extra for a Printrbot. Thing’s hardcore. If you want to verify/calibrate, go here. Otherwise it should Just Work.

this ‘tiny house’ trend is getting ridiculous

If you have Rev. D and these binaries don’t let the printer home right, let me know – I don’t have that version to test on and I’m curious about that probe behavior…