Vorstellung industrieller Datenlogger mit AVRco

Really impressive work! I can only imagine amount of effort put into this product. It looks very nice. I use a lot of loggers, but they are in quite a different league. They are mostly all Linux based, gather data and store it internally, have web interface and/or color touch screen. They are all connected to some historian (like Osisoft PI or Industrial SQL) via OPC server communicating with the logger (mostly MODBUS RTU and TCP). To name a few: Siemens Sirec, Honeywell, Yokogawa... I know you are not competing with them with your product, but let me share some "insider" thoughts what can you do to make your logger more attractive to plant maintenance managers who make the purchasing decisions after consulting production needs and his engineers/technicians. Most Level 0 analog signals are 4-20mA. Although there are converters to 0-10V you should support 0-20mA and 4-20mA signals directly. You should also support some well known industrial communication protocol. MODBUS is most widely used, and you can't go wrong with it. 95% of loggers I deal with support it. That way, your Level 1 logger can be connected to some plant historian software and collected data can be used with some Level 2 application to show trends and reports to the management or analyze data in spreadsheets. MODBUS TCP is the most wanted protocol, but unfortunately it is not yet supported by AvrCo (only MODBUS RTU and MODBUS ASCII are supported over RS232/485). Luckily, there are many protocol converters (like some MOXA devices) that can convert MODBUS RTU or MODBUS ASCII to MODBUS TCP. Although MODBUS ASCII is much nicer for your MCU since it doesn't use additional interrupt, you will probably want MODBUS RTU since it is much wider used. So, after this beeing done, you could offer your customers both MODBUS RTU and TCP (TCP is optional with an additional adapter). After this, nothing stops you from offering some 3rd party OPC server (de facto universal communication standard in industry) like KepWare OPC server with MODBUS plugin driver, or Matrikon MODBUS OPC Server. With all this, your logger provides data not to just one PC on someone's desk, but to the whole factory - operators, technologists, technicians, managers... There are even OPC enabled alarming products that can send SMS or e-mail in case of some tags having alarm values. One thing is also important for loggers - to see trends on site. Unfortunately, you didn't use graphical display, but there might be a way to implement rudimentary trend even with character based display. You can use top line to display tag name, engineering units and numerical value, and bottom 3 lines can be used for a graphical trend. How? Well, you can make 7 user defined characters each one having only one solid horizontal line in 5x7 character matrix (1st UDF char having 1st line solid and other 6 lines empty, 2nd UDF char having 2nd line solid and other 6 lines empty...). That will give you 3 char lines x 7 lines per char = total of 21 dots of vertical resolution, and 20 chars = 20 (wide) dots of horizontal resolution. Not much but enough to see the trend of the tag, which is sometimes essential for on site operators and technicians. Having HTTP real time trends would also be nice, but would probably add to much of a complexity to the project, and you would still be limited in number of connections to the device, which could bring more trouble then benefits if a lot of users try to monitor trends with their browser at the same time.
Please do not take this as a critique, but as an bunch of ideas for V2.0, V3.0... Even if you do not implement any of this, you still have an impressive piece of work - with an AVR inside! Wish you well!

You are quite right about ease of interfacing 0-20mA sensors, but you are thinking from your point of view where you assume that everyone interested in such a feature has knowledge and will to do it. From my experience in many plants maintenance you mostly have manager(s) with bunch of electricians, technicians, process control and instrumentary guys. When a production asks for some new sensors, technical solution decision is driven partly by device interfacing features. If 0-20 or 4-20mA signal is in question, NO ONE in a big plant will purchase a device that doesn't have this feature out of the box (and big plants are one of your targets in a long term since they purchase tens of devices at once), and no one in the plant will get the job to make the needed custom electrical interface. Even if the knowledge is there. The reason is that they will not risk their production with some custom solution, when there is already a proven solution. They will pay much more if needed, to have a 24/7 sleep. Even if something goes wrong with a branded device, no one can blame the one who ordered it since he bought the best there is. I think you get the picture how hard it is to sell your devices to big plants. It would be wise to not make it even harder just because you don't have a 0-20mA or 4-20mA interface. If you don't want to mess with existing PCBs then you can make an adapter which you can also sell. I don't remember if you had an interface to various thermal sensors, but that is also interesting in a plant floor (although more complicated).

Linear equation is quite common, but you can extend transfer function from simple linear form y(x)=k*x+n to more general polynomial form y(x) = c0*x^0 + c1*x^1 + c2*x^2 + c3*x^3 + ... This can be very nicely applied in electronics since all non-linear sensors I have dealt with so far could be curve fit with just 4-5 polynomial coefficients (c0, c1, c2...) and therefore very accurately linearized without big tables and with just simple math. You can find nice free curve fitting software that finds these polynomial coefficients out of any X-Y table here: http://www.xlxtrfun.com/XlXtrFun/XlXtrFun.htm
An example process goes something like this... Let's say you have some nonlinear sensor (like temperature), and you already have a x,y table from the datasheet or you make your own table for a totally unknown sensor by heating it and writing down temperature/resistance pair values. Then you use XlXtrFun or some other software for curve fitting to find polynomial coefficients. You try 4, 5 and 6 coefficients, and you see that curve is accurate enough with 5 coefficients. Then you write them down and they are ready to be used for converting raw measurements to engineering units. Very nice and convenient.