Search the Community

Showing results for tags 'block'.

More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • Frontpage, Forum Information and General LEGO Discussion
    • New Member Section - PLEASE READ BEFORE STARTING!
    • Frontpage News
    • Forum Information and Help
    • General LEGO Discussion
  • Themes
    • LEGO Licensed
    • LEGO Star Wars
    • LEGO Historic Themes
    • LEGO Action and Adventure Themes
    • LEGO Pirates
    • LEGO Sci-Fi
    • LEGO Town
    • LEGO Train Tech
    • LEGO Technic and Model Team
    • LEGO Mindstorms and Robotics
    • LEGO Scale Modeling
    • LEGO Action Figures
    • Special LEGO Themes
  • Special Interests
    • The Military Section
    • Minifig Customisation Workshop
    • LEGO Digital Designer and other digital tools
    • Brick Flicks & Comics
    • LEGO Mafia and Role-Play Games
    • LEGO Media and Gaming
  • Eurobricks Community
    • Hello! My name is...
    • LEGO Events and User Groups
    • Buy, Sell, Trade and Finds
    • Community
    • Culture & Multimedia

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start



What is favorite LEGO theme? (we need this info to prevent spam)

Which LEGO set did you recently purchase or build?



Website URL








Special Tags 1

Special Tags 2

Special Tags 3

Special Tags 4

Special Tags 5

Special Tags 6

Country flag

Found 5 results

  1. Now that my semester is mostly over, I've been thinking about some of the projects I had to put on hold to focus on my senior design project this year - specifically, the PCB I developed a couple years ago to run two three-color track signals off a centralized microcontroller: The original design called for a three-color signal: red, yellow, and green. My plan was to divide my layout into blocks, with a signal placed on each block. I wanted my signals to respond in the following manner: - If a train is detected in a block, that block's signal must be red (block is occupied). - The signals in the blocks adjacent to occupied blocks must be yellow (block ahead is occupied). - Otherwise, the block signal will be green (block is unoccupied). This would result in the signals 'following' the train around the layout, such that any trains travelling on the same track would be aware of each other, hopefully avoiding collisions. In practice, I won't be running trains on the same track, but it's still a fun effect to have! My resulting truth table then looks like the following. Inputs A and S are the signals from the adjacent blocks and block sensor, respectively, while outputs R, Y, and G are the red, yellow, and green signals, respectively. It doesn't matter which 'side' I get a signal from an adjacent block, as either way I want the signal to turn yellow. In addition, if the block sensor sees a train, I don't care what the adjacent blocks are doing - the signal must turn red. After working through this table, it occurred to me that there were two ways I could build this signal controller... Form 1: NAND Logic This truth table is simple enough that I should be able to build it with basic logic gate ICs - and if I can do that, then I can do it purely with NAND logic gates, saving cost as I only need one type of chip to make this work. However, I still need to work on converting the truth table to a set of Boolean expressions, and from there into pure NAND logic. After doing a bit of research, it looks like I'll need multiple NAND chips, as most chips I find have only four gates inside them. However, I am space and cost limited, as I can only use four NAND chips (16 NAND gates) if I want to be comparable to the cost of the ATTiny85 at 36 cents per chip. Form 2: ATTiny85 Since I only have five inputs/outputs, the ATTiny85 microcontroller is perfect for this application - there are exactly five pins left over after accounting for power, ground, and reset. However, I would need to program each microcontroller, and doing so with a surface-mount device becomes problematic. The cost is also an issue, as each one costs about $1.16-1.25. Buying in relatively small quantities, I think I can get the cost of components for each board to about $5 per board - including connectors and such. The main issue with using NAND gate chips is the amount I'll need, and thus the space they'll take up on a size-limited board. I also will need some transistors to drive the LEDs as the logic chips can't drive that much current directly. The issue with using an ATTiny85 chip for each board is how to program the much smaller surface-mount versions, as well as the relatively large fixed cost of each chip - I can't work on optimizing out some of the cost in the same way I could with the NAND version. I want to use JST connectors for running cables between the boards and sensors and such, as they're directional and I don't have to worry about plugging things in backwards this way. There is another question I have for you all: what's the most useful form factor? My original project had a board that was designed to fit in a 4x4 stud area, but for this I'm leaning more towards a 2x6 or 2x8 board, as I think I can fit that into more spaces.
  2. Not really, but I found out that the motors in my GX EV3 peform better in IR Control mode than how they do in my program, and I believe that it is because the motor power is different. Each block in the EV3 programming software that moves the motors has a digit for how much power each motor should have. I'm wondering what this digit is in IR Control mode, because the motors act much better in this mode than how the do in the program. If anyone here knows the power of the motors when the EV3 brick is in this mode, please reply as soon as possible. It would be very appreciated.
  3. I'm taking the knowledge I learned from a class last semester and applying it to my long-term layout. The devices pictured here form the basis of a block-occupancy detector system that will be placed within my long-term layout to facilitate some autonomous functions, such as signals, automatic level crossings, and remote switching. To start with, let's have a quick look at the FPGA development board I'm using for the controller. This is the Basys 3 Artix-7 FPGA Trainer board, sold by Digilent. The Artix-7 FPGA chip used here has 33,280 logic cells divided into 5200 slices (each slice containing four 6-input LUTs and eight flip-flops). It runs off of a 5V power supply, delivered either through USB or an external power jack. There are four 2x6 'PMOD' connectors (standard spacing, thankfully), one of which also acts as an analog input. There is also a VGA connector and a full-size USB as well. In addition, there are 16 switches and five pushbuttons available, as well as 16 LEDs that can be accessed by the user. It uses the Xilinx Vivado Design Suite for programming. Next, we have the sensor I'm currently using. ...Or at the very least, something very similar to it. It's one of those fairly generic designs that's copied by everybody and sold for very little, so it doesn't really matter which one you get so long as it looks the same. This, however, is not the final sensor I'll be using - this design is extremely directional, in that it's only sensitive enough for my application when the light source is in front of the module. It turns out that the version which has a photoresistor as its light-sensitive element is much better at detecting the ambient light level, and is actually somewhat cheaper. These type of sensors will run happily on anything from 3.3-5V, and have two outputs: an analog output, which will vary its voltage from 0V up to the voltage of the supply, and a digital output, which operates in the reverse of what you'd typically expect - that is, it outputs a high signal (high being the voltage of the supply) when the light level is below the trigger point set by the potentiometer, and outputs a low signal whenever the light level is above the trigger point. There is one power LED and an LED that reflects the opposite state of the digital output. In my first picture, I have attached the VCC pin of the sensor to one of the VCC connections on the Basys 3 - pins 6 and 12 on the PMOD connectors act as 3.3V supplies, with pins 5 and 11 acting as a ground, and pins 1-4 and 7-10 acting as signal lines - and the GND pin on the sensor to one of the ground connections on the Basys 3. The digital output (DO) on the sensor is connected to one of the signal lines on that same PMOD connector, and the analog output (AO) is left unattached (if I connect AO to a ground connection, the sensor acts as if a bright light is in front of it no matter what). Next, we have to write the code that defines the behavior of the controller! FPGAs are interesting because rather than a microcontroller executing commands, the code written actually tells the FPGA to re-wire itself internally to produce hardware-only logic that provides the desired behavior (this is where the name Field-Programmable Gate Array comes from). As such, the code isn't written in C or Java, but in Verilog and other Hardware-Descriptive Languages (HDLs). The code files can be treated as individual 'blocks' of logic, and can easily be combined together to produce much more complex behaviors than we see here. This is the only Verilog module that runs the system currently: module bodsensortest(led,bodsensor); output led; // Goes to some LED on the Basys 3 input bodsensor; // Comes from AO on the sensor board assign led=!bodsensor; // Oddly enough the AO output is an inverse output - it goes LOW when the light level is above the trigger point endmodule Here I'm defining a module called 'bodsensortest', with the output 'led' and the input 'bodsensor'. Then I tell the Basys 3 to set the output 'led' to the opposite state of 'bodsensor'. In addition to building the actual logic, it's advised to write a testbench module that hooks up to your first module and allows you to simulate it before sending the code off to the board: `timescale 1ns/100ps module tb_bodsensortest; reg tbodsensor; wire tled; bodsensortest dut(tled,tbodsensor); initial begin $dumpfile("tb_bodsensortest.vcd"); $dumpvars(0,tb_bodsensortest); tbodsensor=0; #40 // Default should be sensor 'uncovered' tbodsensor=1; #40 // Sensor now 'covered' #20 $finish; // total sim time: 100ns end endmodule Here I define the units of time that I'm simulating in, the module, and inputs (reg) and outputs (wire) for the testbench file. Then I tell the system to create a .vcd (timing diagram) file, and in that file examine ALL variables within the testbench file. Then I toggle the state of tbodsensor off and on to simulate something passing over the sensor, with some delays. Finally, I add in a 20ns delay to round it to a nice number. Lastly, in order to actually make this work on the board, I have to play with a constraints file that tells the board what I/O pins to look at and what variables they correspond to: ## This file is a general .xdc for the Basys3 rev B board ## To use it in a project: ## - uncomment the lines corresponding to used pins ## - rename the used ports (in each line, after get_ports) according to the top level signal names in the project ## LEDs set_property PACKAGE_PIN U16 [get_ports {led}] set_property IOSTANDARD LVCMOS33 [get_ports {led}] ##Pmod Header JA ##Sch name = JA10 set_property PACKAGE_PIN G3 [get_ports {bodsensor}] set_property IOSTANDARD LVCMOS33 [get_ports {bodsensor}] Here I'm telling the Basys 3 that one of the LEDs on the board is the output from the first module, and the input for that module comes from one of the PMOD connections. After this, I plug these files into the Vivado software, and generate a file that's sent to the board. Because FPGAs are volatile, I also told the software to generate a configuration file that's saved in flash memory on the Basys 3 so it can automatically re-configure itself every time I turn it back on, rather than having to reprogram it with a USB. Otherwise, I would only be able to run this program until the Basys 3 was turned off! All of this makes a little LED on the board turn on and off Also, I've actually got the function backwards - I want the module to follow the backwards behavior of the sensor, as I want there to be a signal whenever a train is passing over the sensor (it makes more logical sense to me that way). However, so far I'm quite pleased with what I've accomplished as we didn't really do much with outside inputs during the class - we stuck mainly to the switches and buttons provided!
  4. After watching a documentary about Puma Punku, I decided to rebuild one of the famous H-Blocks with LEGO-bricks. I tried to build it as small as possible (2x4 brick for comparison) without losing too much of the original measurements/aspect ratio...