You’re right, I wasn’t thinking about per-spool data (which I don’t expect to see soon), only the data that is the same for all spools of the same SKU. I like the idea of implementing the parsing algorithm in javascript. It would make in-slicer data fetching a little harder to implement, but you could still write a script to save out a pre-configured config file as well as displaying the included information in a human-readable form and even fetching extended information if the script includes a lookup table of the manufacturer codes and their link structures. Alternatively, they could include their own URL and host a copy of the javascript so that the information is displayed on their own site (this would probably be the preferred method, with the centrally-hosted page as an alternative option).
The beauty of an open protocol, that uses the BB as part of the URL is really the flexibility. (IMHO) the BB could in theory be directly writable to the cartridge (just drop header/footer), if you needed to update, it could be recompiled through JS and the user could reprint for future reference, QR generation could be done in a JS (giving vendors more flexibility for either using the hosted page, If it is open source the manufacture could run it on their server for extend data (use the FID and some lookup data to provide MSDS or other material specific data). It could save a lot of space and keep it interpretable by humans (could allow the JS to be run in a local host environment for person with unstable internet connections)
BTW I think we should move this back to the community to allow for reference later.
I was thinking the same thing. I’ll post something.
i am writing a really brief post with respect to the basic URL js stuff. if you want to get the data formatting and binary info discussed written up.
I’m not so sure that the URL stuff is realy helpfull. To encode a URL we need to use either A/N or Binary (with assumed 8859). For a V4M this means we got 90 (A/N) or 62 (8859) characters - and these will have to include at least 12 character of decoration (http://…org/…) - with the way @Camerin_hahn proposes way more (20+). This is like super bloar compared what we discussed before. Not realy a way to transport anything.
Also, and this is way more serious, it will kill the self contained nature. With @Whosa_whatsis original idea, the information is available to the printer (or whatsoever local environment of the user), all time and as long as the QR/chip is readable. Now it’s useless if there is not internet connection.
Furthermore, whats with spools siting for a few years before used? How will you make the service not only reliable, but also available for a time similar to how long a filament is usable (make that 20+ years)? No distrust in @Camerin_hahn , but there have been quite some projects that ended up in http://archive.org way before their usability ended.
This idea is an dead end.
Ach ja - I had all the time the feeling we missed some serious issue. having slept, I finally can point it out:
How does the data get transfered from the chip to the printer?
Obviously you need some wires connected. HOW?
@Hans_Franke Again, the URL idea is only so that there will always be a way to read the QR code, so it can be scanned with any software, not just one that is expecting this protocol, It will be ignored by anything that already understands the protocol. It does not affect how the rest of the code will be formatted, because it will pass as a binary blob in the query string of the URL. Doing it that way only means that we can’t use the QR code’s other native data types to store the data, which wouldn’t help because we still need an interpreter to break it into the various values.
The data will be written to the EEPROM using an M code that will have to be implemented in any firmware supporting use of the EEPROM, with the EEPROM connected to the printer the same way it will be when it is read by the printer. I thought that was obvious. At first, the M code will have to be externally generated (it will be one of the things on the web page version) and copy/pasted into the host software. Eventually, the host softwares should support scanning the QR and sending the M code natively.
@Hans_Franke I think @Whosa_whatsis described it well, but the brief explanation would be (assuming everything was done as it is stated right now). (@Francois_Lapierre this will be high level so I hope it is clear, if it isn’t please let me know, we need to find a way to make it clear to everyone)
Scan QR, it contains a link
Links is formatted as http://UFIS.org/#[machine_readable_code]
from here you have two options:
1: delete everything up to # and program an EEPROM through a 1-wire communication adapter (IE, buspirate or via a microcontroller)
2:navigate to the URL, the URL will give you human readable values that you could simply put in your slicer.
Currently we do not have an EEPROM solution. that is probably some time out (firmware needs to be rewritten, EEPROM needs to be sourced, Lots of legwork to be done)
@Camerin_hahn Well, not sure if adding tunnels to it makes it more usable. And for sure we now need at least a V6 (or bigger) QR to incooperate the URL-Overhead.
Also it opens quite some scurity considerations. For example, how do we make sure that neiter the domain, nor the script in question get hijacked? And this means long term stability. Not just today or tomorrow, but in 20 years from now. Or is there a way to avoide that manufacturers will put their own URL in front (which still would make it compatible to your solution considering the use of the binary part)? They may see it as an ‘enhanced’ service - and beliv me, that wouldn’t be the first domain going to some strange guys after the company lost interest or went belly up.
Call me a negative old fart, but I don’t belive in just frolicing for the sunny side.
Hmm… I have the feeling we are missing something important. Maybe before talking about content, data formats, and possible tunnels to add usability, we should look for some basic requirement. Someone already mentioned this way back (forgot the name, sorry).
We need a first a spec about
What the data are to be used for
In what way they are used
What additional goals may be reached.
Maybe with a backgound why the idea came up in first place as a preface.
Only after that has been specified solutionds can not only be suggested, but also checked against the requirement - and einter accepted, rejected, or the spec updated 
@Whosa_whatsis can you do this?
Acting structured supports success.
@Hans_Franke How would the URL or the site getting hijacked destroy the protocol, I have said many times the website only provides human readability. If the website disappears, the binary is not changed.
The printer never ever pings the server.
All of the data is stored on the QR
The HTML will be open source, you could run a copy locally, you would need to rewrite the URL to point to the local copy, but it would work
The data would be used to pass hold recommended printer setting. Right now as a user you must guess and test (you only get ball park numbers), knowing the exact diameter of the filament, printing is not possible. The thermal properties of the filament are important to print quality. there are 3 different numbers for that (hot end temp, bed temp, and surrounding area temperature). the rest is information about the manufacture, it is not necessary for anything, but tracking.
what is wrong with the URL, it is not part of the data structure, it is a link to how to read the data?
Also remember the max size of the data is much smaller than size of the QR (the QR can hold 10 times the data of the EEPROM)
@Camerin_hahn I perfectly understand what you intend to do. and it’s a great idea on first sight.
The security concern is not about the Printer, it’s about the handling you described: The user takes a picture of the QR and hits GO, trusting that we made sure that he gets waht he wants, not some virus injection.
@Camerin_hahn
Size of OR
A V4M QR can hold 62 (8 bit) characters. This is a rough equal to what sugested for the EEPROM (512 Bit/64 Byte). if you add an URL, you come with somewhere arround 15 to 30 Characters needed in addition. Since we need 8 bit encoding to use your proposed URL scheme (as far as I understand. O couldn’t find any real example from the website you pointed out, so please correct me if it works different), we now need some 90+ chars, that will be (if we stay with M-type correction) a V5 or V6 QR code. doesn’t sound big, still most application do not use anything above V4, since some phones (and apps) still have problems with larger encodings.
Also consider that so far, we’re not using the whole 512 bits. We need about 22 bytes IIRC for the binary data we have already come up with, plus 20 (assuming full-byte encoding) for a 20-character “name” field. I was thinking about adding room for a short url, but the QR scheme with one at the front makes that unnecessary.
@Hans_Franke that still doesn’t answer, what is wrong with the URL? with out it is not legible. Also I don’t think phones are our target market, they don’t communicate with printers.