Any idea regarding the usual storage capacity of a magnetic swipe card ( like the ones that are used in ATM's ) ?
(PS : Tried googling but didn't get anything satisfactory and point on)
From http://en.wikipedia.org/wiki/Magnetic_stripe, it appears that the card is composed of three tracks (as previously mentioned by Pax), and Tracks 1 and 3 have a bit density of 210 bits/inch, while Track 2 has a bit density of 75 bits per inch.
If the strip is 3.25" long, then it can theoretically store 1607 bits, with 682 on each of Tracks 1 and 3, and 243 on Track 2.
ISO 7813 specifies the layouts for track 1 and 2. Track 3 is covered by ISO 4909.
Track 2 is the one commonly used for banking.
See ISO7813 and ISO4909 for details. Sorry, no wikipedia for 4909, you'll have to buy the docs from ISO or your country's standards body.
Related
I was doing some research over the weekend on some blockchain dev in the Solana blockchain and came across a construct called Compact-u16. The definition of this in the documentation says the following: "A compact-u16 is a multi-byte encoding of 16 bits. The first byte contains the lower 7 bits of the value in its lower 7 bits. If the value is above 0x7f, the high bit is set and the next 7 bits of the value are placed into the lower 7 bits of a second byte. If the value is above 0x3fff, the high bit is set and the remaining 2 bits of the value are placed into the lower 2 bits of a third byte.".
I have been coding for 30+ years. Maybe I'm just old school on this, but why is there a construct to store 16 bits of data in 3 bytes? This is just vastly inefficient from my standpoint. Is there a reason for this? On further research, I found a doc related to assembly instruction pointers, which referenced 7 instruction pointers that are useful for caching values when context switching in and out of the processor stack. But this construct is used for a web app platform. Like, literally, there is no reason that I have been able to find that justifies using 3 bytes to store 16 bits of data. If the developers wanted to use an elegant bit mapping solution to compress space, why not just use a semaphore? Why create a brand new construct that increases the storage requirements for the data by 33%.
What am I missing?
I had some similar confusion when reading the compact-u16 description. Based on the code for parsing them in the solana python module I believe they're doing something conceptually similar to UTF-8, and storing the number in 1-3 bytes depending on its size.
Basically instead of each byte having 8 bits of a number, it has 7 bits of the number and a flag (the most significant bit) that indicates whether the number continues in the next byte. For the largest numbers they need an extra byte, but for numbers less than 128 they need only one byte. Since Solana seems to use these for storing the length of arrays, if it's common that the length of the arrays is less than 128 then they will end up with fewer total bytes to transfer across all transactions.
Some examples I worked out for myself:
hex | compact-u16
--------+------------
0x0000 | [0x00]
0x0001 | [0x01]
0x007f | [0x7f]
0x0080 | [0x80 0x01]
0x3fff | [0xff 0x7f]
0x4000 | [0x80 0x80 0x01]
0xc000 | [0x80 0x80 0x03]
0xffff | [0xff 0xff 0x03])
I'm trying to report battery information for a battery-powered HID device (USB when plugged, BLE otherwise). Reading through the report descriptor from the example in Appendix A of Usage Tables for HID Power Devices (v1.1) I see two collections for reporting data about the battery to the host:
UsagePage(Power Device), Unit(none),
Usage(PresentStatus), Collection(Logical), ; Present status collection
Usage(Good),
UsagePage(Battery System), Usage(BelowRemainingCapacityLimit),
Usage(Charging), Usage(Discharging),
ReportSize(1), ReportCount(4), Logical Minimum (0), Logical Maximum (1), Unit(0),
Feature(Constant, Variable, Absolute, Volatile),
End Collection(), ; End of Present Status collection
UsagePage(Power Device),
Usage(ChangedStatus), Collection(Logical), ; Changed Status collection
Usage(Good),
UsagePage(Battery System), Usage(BelowRemainingCapacityLimit),
Usage(Charging), Usage(Discharging),
ReportSize(2), ReportCount(4), Logical Minimum (0), Logical Maximum (1),
Input(Data, Variable, Absolute, Volatile),
End Collection(), ; End of Changed Status collection
I only have a LiPo battery and a diode to charge it, so I am planning on taking out much of the rest of the power device stuff since I think I can get everything I want from the Battery System usage page. As a result I am looking at something more like (feel free to tell me if this is doomed form the start):
UsagePage(Battery System), Usage(BelowRemainingCapacityLimit),
Usage(Charging), Usage(Discharging),
ReportSize(1), ReportCount(3), Logical Minimum (0), Logical Maximum (1), Unit(0),
Feature(Constant, Variable, Absolute, Volatile),
Looking at the report from the spec, I have two questions:
Why is CapacityMode only size 1? The values are 0 - 3, isn't that a size 2?
What actually goes into the ChangedStatus collection? I see that the report sizes are 2 instead of 1 - are the reporting the old status on there as well? I'm not seeing anything elsewhere in the spec that gives an indication. In fact, the spec says that ChangedStatus elements should be boolean, which should be size 1, no?
CapacityMode can have values 0 to 3, but if your device only supports mode 0 (capacity measured in milliamp-hours) or mode 1 (capacity measured in milliwatt-hours) then I think it is ok to have a 1-bit wide field to record this. You could even define an 8-bit field that only stores the values 0 or 1 even though it could hold values up to 255.
I think the authors of the examples may have been trying to align the fields into 8 bits by making each of the 4 status bits 2-bits wide - so 0, would be stored as 00 and 1 would be stored as 01 in the report. Or it could have been a typo - I have seen many other examples in the USB specifications that have errors in them.
I'm trying to model the flow and suspension of microcarriers (particles that are used as surfaces for cells to attach to and grow on) in a CFD application. I know some basic characteristics of the particles (they're called "Cytodex", about 180 µm big, density is 1.03g/cm^2) but I'd like to find the Stokes number to determine how strongly they are affected by turbulence and movement of the fluid. Can somebody point me to how to approach this (or at least approximate?). It's surprisingly hard to find any information for somebody like me who hasn't got a very strong background in fluid mechanics.
Here is the manufacturer's microcarrier manual. See page 62, Table 12 for Cytodex 1 physical properties.
https://www.gelifesciences.co.kr/wp-content/uploads/2016/07/023.8_Microcarrier-Cell-Culture.pdf
See this SlideShare, slide 15, for how to calculate the Stokes # for Cytodex 1 microcarriers: https://www.slideshare.net/rjrishabhjain/bs-4sedimentation?from_action=save
but for Cytodex 1 correct the d=180 um, for cell culture media=nutrient broth viscosity = 0.96 cP, media density ~ 1.007g/mL, microcarrier density 1.03 g/mL, to get settling velocity of 0.062cm/s = 3.72 cm/min. However, per the manufacturer's manual settling velocity is 12-16mL/min. Might be an error. I am seeing an answer.
For CFD modeling of microcarriers in bioreactors see: Loubière
https://pdfs.semanticscholar.org/d955/75b5c640c8268fd1ec51b2ce46862e7bbfbd.pdf
I have more related literature if you have interest.
DApple
I am trying to decode the Hex data sent by the device to my server. I am able parse the latitude , longitude ,speed etc. But what I am unable to decode is the 'state' information. I believe they represent the state of the vehicle e.g. oil and electricity, ignition on/off etc.
I cant find any document which can guide me as to how to decode the 8 bits of state and what each bit represents.
Any help or documentation for the same will be appreciated.
This is what I have been able to find out.
8 bits of IO:
First bit represents Power : 0 indicating on, 1 indicating off
Second bit represents Ignition status: 1 indicating ACC on, 0 indicating ACC off.
Other reservations.
Source: http://www.traccar.org/docs/protocol.jsp
Probably state is related to Valid / Invalid position.
Try it out, by comparing the value when having GPS free view to sky, and without (disabel Antenna, shield with metall paper trash bin or metall foil.
If this may help, I just release a new server base on a jison grammar to make protocol easier to implement. https://www.npmjs.org/package/gpsdtracking
I'm not talking about algorithmic stuff (eg use quicksort instead of bubblesort), and I'm not talking about simple things like loop unrolling.
I'm talking about the hardcore stuff. Like Tiny Teensy ELF, The Story of Mel; practically everything in the demoscene, and so on.
I once wrote a brute force RC5 key search that processed two keys at a time, the first key used the integer pipeline, the second key used the SSE pipelines and the two were interleaved at the instruction level. This was then coupled with a supervisor program that ran an instance of the code on each core in the system. In total, the code ran about 25 times faster than a naive C version.
In one (here unnamed) video game engine I worked with, they had rewritten the model-export tool (the thing that turns a Maya mesh into something the game loads) so that instead of just emitting data, it would actually emit the exact stream of microinstructions that would be necessary to render that particular model. It used a genetic algorithm to find the one that would run in the minimum number of cycles. That is to say, the data format for a given model was actually a perfectly-optimized subroutine for rendering just that model. So, drawing a mesh to the screen meant loading it into memory and branching into it.
(This wasn't for a PC, but for a console that had a vector unit separate and parallel to the CPU.)
In the early days of DOS when we used floppy discs for all data transport there were viruses as well. One common way for viruses to infect different computers was to copy a virus bootloader into the bootsector of an inserted floppydisc. When the user inserted the floppydisc into another computer and rebooted without remembering to remove the floppy, the virus was run and infected the harddrive bootsector, thus permanently infecting the host PC. A particulary annoying virus I was infected by was called "Form", to battle this I wrote a custom floppy bootsector that had the following features:
Validate the bootsector of the host harddrive and make sure it was not infected.
Validate the floppy bootsector and
make sure that it was not infected.
Code to remove the virus from the
harddrive if it was infected.
Code to duplicate the antivirus
bootsector to another floppy if a
special key was pressed.
Code to boot the harddrive if all was
well, and no infections was found.
This was done in the program space of a bootsector, about 440 bytes :)
The biggest problem for my mates was the very cryptic messages displayed because I needed all the space for code. It was like "FFVD RM?", which meant "FindForm Virus Detected, Remove?"
I was quite happy with that piece of code. The optimization was program size, not speed. Two quite different optimizations in assembly.
My favorite is the floating point inverse square root via integer operations. This is a cool little hack on how floating point values are stored and can execute faster (even doing a 1/result is faster than the stock-standard square root function) or produce more accurate results than the standard methods.
In c/c++ the code is: (sourced from Wikipedia)
float InvSqrt (float x)
{
float xhalf = 0.5f*x;
int i = *(int*)&x;
i = 0x5f3759df - (i>>1); // Now this is what you call a real magic number
x = *(float*)&i;
x = x*(1.5f - xhalf*x*x);
return x;
}
A Very Biological Optimisation
Quick background: Triplets of DNA nucleotides (A, C, G and T) encode amino acids, which are joined into proteins, which are what make up most of most living things.
Ordinarily, each different protein requires a separate sequence of DNA triplets (its "gene") to encode its amino acids -- so e.g. 3 proteins of lengths 30, 40, and 50 would require 90 + 120 + 150 = 360 nucleotides in total. However, in viruses, space is at a premium -- so some viruses overlap the DNA sequences for different genes, using the fact that there are 6 possible "reading frames" to use for DNA-to-protein translation (namely starting from a position that is divisible by 3; from a position that divides 3 with remainder 1; or from a position that divides 3 with remainder 2; and the same again, but reading the sequence in reverse.)
For comparison: Try writing an x86 assembly language program where the 300-byte function doFoo() begins at offset 0x1000... and another 200-byte function doBar() starts at offset 0x1001! (I propose a name for this competition: Are you smarter than Hepatitis B?)
That's hardcore space optimisation!
UPDATE: Links to further info:
Reading Frames on Wikipedia suggests Hepatitis B and "Barley Yellow Dwarf" virus (a plant virus) both overlap reading frames.
Hepatitis B genome info on Wikipedia. Seems that different reading-frame subunits produce different variations of a surface protein.
Or you could google for "overlapping reading frames"
Seems this can even happen in mammals! Extensively overlapping reading frames in a second mammalian gene is a 2001 scientific paper by Marilyn Kozak that talks about a "second" gene in rat with "extensive overlapping reading frames". (This is quite surprising as mammals have a genome structure that provides ample room for separate genes for separate proteins.) Haven't read beyond the abstract myself.
I wrote a tile-based game engine for the Apple IIgs in 65816 assembly language a few years ago. This was a fairly slow machine and programming "on the metal" is a virtual requirement for coaxing out acceptable performance.
In order to quickly update the graphics screen one has to map the stack to the screen in order to use some special instructions that allow one to update 4 screen pixels in only 5 machine cycles. This is nothing particularly fantastic and is described in detail in IIgs Tech Note #70. The hard-core bit was how I had to organize the code to make it flexible enough to be a general-purpose library while still maintaining maximum speed.
I decomposed the graphics screen into scan lines and created a 246 byte code buffer to insert the specialized 65816 opcodes. The 246 bytes are needed because each scan line of the graphics screen is 80 words wide and 1 additional word is required on each end for smooth scrolling. The Push Effective Address (PEA) instruction takes up 3 bytes, so 3 * (80 + 1 + 1) = 246 bytes.
The graphics screen is rendered by jumping to an address within the 246 byte code buffer that corresponds to the right edge of the screen and patching in a BRanch Always (BRA) instruction into the code at the word immediately following the left-most word. The BRA instruction takes a signed 8-bit offset as its argument, so it just barely has the range to jump out of the code buffer.
Even this isn't too terribly difficult, but the real hard-core optimization comes in here. My graphics engine actually supported two independent background layers and animated tiles by using different 3-byte code sequences depending on the mode:
Background 1 uses a Push Effective Address (PEA) instruction
Background 2 uses a Load Indirect Indexed (LDA ($00),y) instruction followed by a push (PHA)
Animated tiles use a Load Direct Page Indexed (LDA $00,x) instruction followed by a push (PHA)
The critical restriction is that both of the 65816 registers (X and Y) are used to reference data and cannot be modified. Further the direct page register (D) is set based on the origin of the second background and cannot be changed; the data bank register is set to the data bank that holds pixel data for the second background and cannot be changed; the stack pointer (S) is mapped to graphics screen, so there is no possibility of jumping to a subroutine and returning.
Given these restrictions, I had the need to quickly handle cases where a word that is about to be pushed onto the stack is mixed, i.e. half comes from Background 1 and half from Background 2. My solution was to trade memory for speed. Because all of the normal registers were in use, I only had the Program Counter (PC) register to work with. My solution was the following:
Define a code fragment to do the blend in the same 64K program bank as the code buffer
Create a copy of this code for each of the 82 words
There is a 1-1 correspondence, so the return from the code fragment can be a hard-coded address
Done! We have a hard-coded subroutine that does not affect the CPU registers.
Here is the actual code fragments
code_buff: PEA $0000 ; rightmost word (16-bits = 4 pixels)
PEA $0000 ; background 1
PEA $0000 ; background 1
PEA $0000 ; background 1
LDA (72),y ; background 2
PHA
LDA (70),y ; background 2
PHA
JMP word_68 ; mix the data
word_68_rtn: PEA $0000 ; more background 1
...
PEA $0000
BRA *+40 ; patched exit code
...
word_68: LDA (68),y ; load data for background 2
AND #$00FF ; mask
ORA #$AB00 ; blend with data from background 1
PHA
JMP word_68_rtn ; jump back
word_66: LDA (66),y
...
The end result was a near-optimal blitter that has minimal overhead and cranks out more than 15 frames per second at 320x200 on a 2.5 MHz CPU with a 1 MB/s memory bus.
Michael Abrash's "Zen of Assembly Language" had some nifty stuff, though I admit I don't recall specifics off the top of my head.
Actually it seems like everything Abrash wrote had some nifty optimization stuff in it.
The Stalin Scheme compiler is pretty crazy in that aspect.
I once saw a switch statement with a lot of empty cases, a comment at the head of the switch said something along the lines of:
Added case statements that are never hit because the compiler only turns the switch into a jump-table if there are more than N cases
I forget what N was. This was in the source code for Windows that was leaked in 2004.
I've gone to the Intel (or AMD) architecture references to see what instructions there are. movsx - move with sign extension is awesome for moving little signed values into big spaces, for example, in one instruction.
Likewise, if you know you only use 16-bit values, but you can access all of EAX, EBX, ECX, EDX , etc- then you have 8 very fast locations for values - just rotate the registers by 16 bits to access the other values.
The EFF DES cracker, which used custom-built hardware to generate candidate keys (the hardware they made could prove a key isn't the solution, but could not prove a key was the solution) which were then tested with a more conventional code.
The FSG 2.0 packer made by a Polish team, specifically made for packing executables made with assembly. If packing assembly isn't impressive enough (what's supposed to be almost as low as possible) the loader it comes with is 158 bytes and fully functional. If you try packing any assembly made .exe with something like UPX, it will throw a NotCompressableException at you ;)