References

This section contains reference pages that aren’t really worthy of a blog article, but still need a home. See the sub-menu for contents.

 

Apache Notes on Virtual Hosts

Defining <VirtualHost *> means that the virtual host matches on all interfaces that a connection might arrive on. In fact, the addr parameter always relates to an IP address in some form (explicitly defined, resolved, or implied by * or _default_) – at this level, we’re defining IP-based virtual hosts.

The use of the wildcard * effectively means that name-based virtual hosting is being used, because it says ‘this virtual host is applicable regardless of which IP the user-agent is connecting to’ – when a request comes in, Apache will try to match it to a virtual host based on ServerName and ServerAlias values defined in the virtual host.

Note that none of this relates to sockets listening on IP addresses and ports, rather it’s a way of defining what resources are used to service a request that has arrived on a listening socket. That is, Apache can be listening on any number of IP addresses and ports, the VirtualHost directives simply state how incoming requests should be handled.

Maths topics to summarise

  • Naïve Bayes’ Classifiers
  • Linear Regression
  • Logistic Regression
  • K-Means Clustering
  • Decision Trees: Information theory & Entropy

2 Replies to “References”

  1. Hello, I landed on your website after long searching about connecting an rfm69 module to a raspberry pi. Unfortunately I have very low technical skill but was interested in receiving data from a few 433mhz door sensors. I saw that you have started a project to receive data from a weather station, but maybe the principle is the same..any suggestion how I could at least see the data in my lubuntu? What are the libraries I should start or is there any piece of software to read data from from transceivers?many thanks for your help.

    1. You need to know more about the signals coming from the door sensors – the frequency and the type of modulation (FSK, OOK, etc.) are the first things you need to find out. Then you need to decide on a suitable receiver. When you’ve worked out how to configure your chosen receiver (some AM/OOK modules need no configuration), you can capture some raw data to figure out the bit-rate and data protocol.

      If you have an existing receiver unit, you may be able to identify the RF chip being used by the original equipment manufacturer – if so, try hooking up a protocol analyser to see how it’s being configured. The code I have here (which has also been forked a couple of times and modified by others elsewhere) can help you dump raw data using an RFM01 or RFM12b module. The configuration registers would likely be very different for other modules. The principles of configuration over SPI will be similar for any other SPI configurable devices.

      None of this is trivial if you have low technical skills, but neither is it particularly difficult if you have the interest and motivation to learn. I’d recommend you get a logic analyser (even low-end) to help you if you want to go ahead and figure this out.

Leave a Reply

Your email address will not be published. Required fields are marked *